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

[Martin Thomson <[e-mail]>]

On 12 April 2015 at 09:55, Ilari Liusvaara <[e-mail]> wrote:
> 1) What is the recommended 0-RTT API model on server side
    (also consider server apps or app implementations that don't
   support 0-RTT)?


This would have to be similar to the client one, which if you recall was either:

    client.addReplayableData(replayable);
    client.connect();

or:

   client.addUnreliableData(unreliable);
   client.connect();
   client.onunreliabledatalost = () => tls.send(unreliable);

You would have to have the server opt in either with:

   server.enableReplayableData(true);
   server.accept(443);

or:

   server.onunreliabledata = data => { /* handle it */ }
   server.accept(443);

I hope my javascript isn't too obtuse.

> 2) What are the semantics of successfully received 0-RTT transfer
   (especially considering the client-side autoretransmit on
   failure)?

This is protocol-defined.

But I imagine that this depends on the model we employ.  Replayable
data could just be consider the start of a stream.  On the other hand,
unreliable data doesn't work very well for a stream mode.  Conversely,
replayable data makes no sense in a datagram mode, but all data is
unreliable there.

>  3) How does 0-RTT interact with ALPN (especially considering
   potential for multiple protocol candidates)?

I imagine that the ALPN from the previous session applies.  If the
client wants to change anything, it probably shouldn't use 0-RTT. Note
that this includes cipher suites and maybe other extensions too.

>  4) Can handshake with attempted 0-RTT be securely downgraded to
   v1.2 (obviously causes the 0-RTT to fail)?

Not safely.  The decision we made at the last meeting (or interim, I
can't remember) was to require that the server make a commitment to
support - or at least to ignore - TLS 1.3 handshake for at least the
validity period of the 0-RTT information.  The 0-RTT messages might be
ignored in DTLS, but they are unlikely to be handled cleanly by a TLS
1.2 implementation.  I would expect a fatal error.

>  5) There is potential footgun if 0-RTT is used with (DH-)PSK: The
   PSK authenticates the connection immediately, but 0-RTT is
   as replayable as ever. What to do with that?

How is that materially different to other suites?

>  6) The same as above, but when attempting to resume a session.
   with a client certificate (since cc is property of session)?

As before, if the information is replayable, then it needs to be
understood by both parties that it is replayable.  And both need to
understand how that is not a concern.  The client certificate doesn't
present a special risk here.  At least not as far as I've been able to
determine.

> 7) What guidance to give regarding what data can be put to 0-RTT,
   considering its replayability?

What guidance do you want?  It's replayable.  If it causes something
to happen that you don't want to have happen twice (or more), then
don't use 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.

> 9) Can server roll over its 0-RTT keys without waiting for the
   previous ones to expire?

Yes, there will need to be a key identifier in the clear that allows a
server to identify which key to use to decrypt the client's flight.

>  10) How is attacker establishing a session (or at least decoding
    server's first application flight) replaying captured
    0-RTT data prevented (since that could leak quite a bit of
    info about what's in 0-RTT blob)? Or not?

Well, the attacker presumably doesn't have the private keys used by
either client or server.  They might be able to cause a replay, but if
we have decent crypto, they aren't able to decrypt anything, nor can
they continue the session.