[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150928023532.GC20842@brightrain.aerifal.cx>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
