On Fri, Oct 7, 2016 at 3:04 PM, Eric Rescorla <e...@rtfm.com> wrote: > > > On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: >> >> On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote: >> > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara >> > <ilariliusva...@welho.com> wrote: >> > > >> > > Also, it is very likely that 0-RTT would need its own read API, >> > > because >> > > it is pretty unlikely that existing API could be safely retrofitted >> > > or even purpose-built unified API be designed that isn't just asking >> > > for security problems via mixing 0-RTT and 1-RTT data. >> > >> > Yes. In particular I think the TLS state machine transitions need to >> > be ordered with respect to the arrival and sending of data. The >> > challenge for a multithreaded program (yes, some programs have >> > multiple threads sending and receiving at once) is making this make >> > sense, or even a single-threaded program where the TLS stack can >> > change state at times not visible to the sending thread. Maybe there >> > is some slop here, like 0-RTT can become 1-RTT on send, but this >> > raises all sorts of problems for receiving. I think we need to require >> > separation in the API. >> >> 0-RTT can't be allowed to become 1-RTT on send (unless it is auto- >> retransmit, which needs to be disableable, as sometimes that just plain >> won't work). > > > Can you explain why that is?
Grammar problems. Let's say you have an context-free parseable protocol, and you want to insert the restriction that there is a 0-RTT set of allowed constructions and an 1-RTT allowed set that is bigger. The most obvious way to do this is to treat the transition as a token that comes between the top-level productions of each set of allowable things: so I send you a bunch of 0-RTT allowed bits, then switch, then a bunch of 1-RTT allowed bits. If the sending stack can insert that transition anywhere the grammar explodes. One could try to handle this by some nasty "did we switch before now" construction to delay the transition. But you still need to switch how you are reading. > > -Ekr > > > >> This impiles that the application always needs to explicitly signal >> the end of 0-RTT data, even just to abort sending it. >> >> > > (This is the reason one needs to be especially careful when combining >> > > dynamic client certificates with HTTP/2... Basically, it can not be >> > > done safely without coordination on application layer). >> > > >> > > One likely wants application protocol to be able to specify part of >> > > or the entiere request context and to extract that part in the other >> > > end when requesting a certificate selection. This is to allow putting >> > > part of coordination data into the request itself. However, this is >> > > not >> > > sufficient for e.g. HTTP/2 signaling, so more needs to be exchanged at >> > > application layer. >> > > >> > > And then upon completion of the authentication (either successful or >> > > explicitly rejected), signal the application with the new certificate >> > > chain and the context the request had. >> > >> > This is going to require major changes to APIs and to the HTTP/2 >> > layer. It also interacts with token binding, whee! My question then >> > becomes one of what we actually need: can we assume that leakage >> > between authentication contexts over a single session is safe because >> > all contexts represent the same principal, by restricting the usages, >> > or is this overly restrictive? >> >> Yes, it is going to reuqire such changes. >> >> And you absolutely can not assume that all contexts present the same >> principal. >> >> And as I said, in multiplexed protocol like HTTP/2, you need application- >> level coordination on top. TLS just can't do that. >> >> > When we have multiple requests and replies in flight and the >> > authentication state changes, things get nasty. If we think of TLS as >> > sending a stream of events including authentication changes to the >> > application, this fits the semantics of the TLS draft as I understand >> > them to be, but does not necessarily fit what application protocols >> > want. There might be a semantic mismatch here requiring reworking of >> > one or another part. >> >> Also, some applications presumably want the events done synchronously, >> so they don't move with data reads. >> >> >> Basically, post-handshake auth is heckuva nasty problem. >> >> >> -Ilari >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > -- "Man is born free, but everywhere he is in chains". --Rousseau.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
