Re: [TLS] Separate APIs for 0-RTT

[David Benjamin <[e-mail]>]

On Wed, Jun 14, 2017 at 5:01 PM Andrei Popov <[e-mail]>
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

>