On Wed, Jun 14, 2017 at 5:01 PM Andrei Popov <andrei.po...@microsoft.com> wrote:
> > - What if the server receives data with the 0-RTT boundary spanning an > HTTP/2 frame? Is that a 0-RTT request? 1-RTT? Invalid? > > It appears safe to treat such data as 0-RTT; only the application can make > this call, and it needs info from the TLS stack to make this call. > I actually would suggest it being 1-RTT. Or rather that a processing-time check would count it as 1-RTT. Though I think I don't see anything particularly wrong with it being 0-RTT either? *shrug* > > > > - We could say that the application profile should modify the protocol > to reject such cases. Now, we’re taking on complexity in every protocol > specification and parser. > > It would of course be preferable (some would argue, necessary) to secure > 0-RTT application_data at the TLS layer, but so far we’ve failed to come up > with a way to do so. > > > > - Our problem is a server wishes not to process some HTTP requests (or > other protocol units) at 0-RTT and needs to detect this case. So check a > boolean signal for whether the connection has currently passed the 1-RTT > point before any unsafe processing. > > I think this would be a valid implementation of #3. There may be other > implementation options that make more sense for a different TLS API or a > different application protocol, so I’d rather not put a specific > implementation option in the RFC. > Sure, if that is the interpretation of #3, that works fine for me. My objection is to trying to pass along a hard separation between the two chunks of data, to the point that the sender actually cares about some data getting sent *before* the boundary. Caring about some data being sent after the boundary is very reasonable and natural. POSTs, perhaps. Before is complex because you must synchronize and defer the boundary. The trouble is a before constraint gets implied by lots of stuff. Specifically, I would propose a looser phrasing for #3: When accepting 0-RTT as a server, a TLS implementation SHOULD/MUST provide a way for the application to determine if the client Finished has been processed. That is, it is not the identity of the bytes that matters much. It's whether the connection has been confirmed when you perform an unsafe action. I believe this still satisfies the properties we want, but without breaking standard interfaces. Very near the TLS stack, at the point where the record boundary abstraction starts leaking (it's common to only give you back a single record on read), either API is equally easy to provide. The looser phrasing is needed for composition once you start going up a layer or to. David >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
