Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 27 Sep 2015 22:35:32 -0400
From: Rich Felker <dalias@...c.org>
To: tlsify@...ts.openwall.com
Subject: Re: Introduction & summary of tlsify discussions, part 3

On Sun, Sep 27, 2015 at 10:20:03PM -0400, Rich Felker wrote:
> The following are excerpts from notes by Daniel Kahn Gillmor (dkg),
> who was part of the CII-Madrid tlsify discussions, originally sent to
> me by email before the tlsify list was setup, and my replies. Reposted
> with permission. The original notes from the workshop were a lot more
> sparse than the expanded version I just sent to the tlsify list, so
> some of the questions below are probably already answered, but I think
> it's still useful discussion.

And one more level of follow-up from that thread:


On Wed 2015-07-22 03:08:15 +0200, Rich Felker wrote:
>> Choice of data channels
>> -----------------------
>> 
>> I'm a little bit confused that it seems to suggest the data channel
>> should be stdin/stdout.  i thought we'd talked about a single forwarded
>> socket, not pipes, since that should have less of an impedance mismatch
>> with the outbound connection.  or is the thought that stdin/stdout would
>> be the comms socket?
>
> C callers wanting to use the socket directly as a primitive would want
> to pass the same socket as both stdin and stdout, but a caller not
> constrained by those requirements could instead use two pipes or could
> even attach one or both to a regular file.

hm, ok, i think that makes sense.  i don't have great intuitions about
what happens if you send() to a regular file, though.

> You're completely right that this was an omission. The set of root CAs
> is certainly an input, but most callers will probably want to use a
> default set or a named set of some sort.

agreed.

> The exact nature such "named sets" might have is unclear to me, but
> could allow an application to say something like "no locally-added
> root CAs" or "restricted root CA set based on zero-tolerance for
> breaches of trust". Obviously directly providing a single
> organizational CA is another usage case, one which should be a lot
> easier to deal with.

yep.  but we could also start the process with an explicit "system
default" set and figure out how to enable fancier features later :)

> It's not clear to me whether this last property is desirable. In
> general every piece of shared/global state is a liability to the
> reliability and security of a system. There is also an option for some
> middle ground where the caller would request a particular
> pinning-store that could be shared or private.

public key pinning without shared state doesn't actually provide any
cryptographic benefits, though :/ i agree that this might be something
we don't worry about for a version-0 system.

> Yes, I'm not sure. One thing I wanted to do in the session on
> Thursday, which we didn't get to, was go over a number of example
> applications and what their needs would be, to start assessing what
> features are the most important to support early and make easy-to-use.

indeed.  I also talked to Andrey Popov from Microsoft (he's one of the
schannel maintainers) and asked him if this approach would be doable on
Windows.  i have no interest in writing that stuff up myself, but for
upstream projects that want to be portable to windows, i figure it's
useful to think about.

> Do you think it's prohibitive (from a usability standpoint or
> otherwise) to just have the caller be responsible for getting the
> session token and passing it in when making new sessions if it wants
> to use session resuming? I suppose it's a matter of whether the caller
> mishandling the token is a greater or lesser risk than the tlsify
> implementation mishandling it. Whichever approach we take, simply not
> using session resuming by default is probably the safest, most correct
> approach. (And with keepalive connections, I'm skeptical that resuming
> even has much value for https.)

session resumption has a lot of value in a lot of contexts.  apparently
some very large (more than half?) fraction of all TLS connections on the
web are resumed connections.

> This is a large part of why I want the "phase 2" to take place: fixing
> the internal TLS implementation not to have so much ridiculous runtime
> overhead. Using static const tables mapped from the executable file on
> disk rather than dynamically initializing tables used for crypto can
> theoretically get the size of the process down to a few pages. The
> base time for posix_spawn is roughly 250-500 us even on slower
> systems, which is negligible in comparison to TLS connection setup if
> I'm not mistaken. So while I think there's possibly some value to
> using a shared process, I question whether it's worth the complexity;
> efforts might be better spent just making the process-per-connection
> more efficient, at least early on.

sure, that seems like a reasonable approach.

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ