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
Powered by Openwall GNU/*/Linux - Powered by OpenVZ