Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay)

[Martin Thomson <[e-mail]>]

On 13 April 2015 at 11:11, Ilari Liusvaara <[e-mail]> wrote:
> I thought the recommended client-side interface called for auto-
> retransmit, which would mean that if application handled 0RTT as anything
> else than a prefix, it would now create two cases serverside.

That retransmit doesn't make sense in DTLS.  I believe that the
current situation is "replayable in TLS", "unreliable in DTLS".

> You mean 0-RTT "KeyIDs" include the application? Note that ALPN is one
> of the very few extensions that is not invariant across resumption
> (might even be the only one that isn't resumption mechanism itself).

They probably need to include the application and more.

> Or guidance that one is to send at most one ALPN identifier if trying
> to send 0-RTT data?

I wouldn't do that: if the 0-RTT state is rejected, then protocol
negotiation is still possible.  I would instead recommend that both
peers remember(or encrypt) certain state to the key identifier and use
that state.

> Also, there's the case 0-RTT is attempted without resumption. Or is
> 0-RTT intended only for session resumption attempts (which would cut
> quite a bit of complexity)?

I don't know how this is intended to work, but I always think of 0-RTT
as resumption.  Nothing much else makes sense.

> There's the case where there are multiple servers behind a load-
> balancer (working at TCP or even IP level).
>
> Inability to gracefully fall back would imply that all servers serving
> something need to be upgraded at once.

Yes, all servers in that farm would need to be upgraded at least to
the level that they would be able to ignore the TLS 1.3 garbage.
Before allowing any node to enable 0-RTT.

>> >  8) If resumption attempt has 0-RTT data, what keying material is
>>    used for the 0-RTT?
>>
>> That combination might not be valid.  If it is, I'm guessing that the
>> first client flight is encrypted and authenticated as a "normal" 0-RTT
>> handshake.
>
> One can't attempt resumption with 0-RTT data?

I don't actually know the answer to this.

> Also, if session is resumed, I think the server won't appreciate having
> to decode "normal" 0-RTT data transmission, since that is relatively
> expensive operation (much more expensive than symmetric decryption of
> reasonable amounts of data).

The server decided to allow that possibility; so it has to deal with
the fallout from it.