[TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

[Karthik Bhargavan <[e-mail]>]

We currently allow 0-RTT with Semi-static DH, with PSK resumption, and with pure PSK.
Whether or not we keep all of these, it would be good to clean up the protocol design 
so that both the client and server have a uniform way of signaling their preferences.

After implementing and analyzing TLS 1.3, here are a few suggestions for discussion.

1) Early Data Extension

The current early-data extension is too DH-specific.
When using PSK, we now have to look at both early_data and pre_shared extensions.
I suggest reusing the same extension for both, with the following interpretation:

	struct {
          select (Role) {
              case client:
                  opaque id<1..2^16-1>;
                  opaque context<0..255>;
                  CipherSuite cipher_suite;
                  Extension extensions<0..2^16-1>;

              case server:
                 struct {};
          	}
	} EarlyDataIndication;


In the semi-static DH case:
- id is the configuration id
- context is the hash of the ServerConfiguration + Server Certificate + CertificateRequest

In the PSK resumption case:
- id is the session ticket
- context is a *public* value unique to the derived session. For example, it could be defined as the session hash of the original handshake,
  or it could be derived by the client as HKDF(RMS, “early data context”)

In the pure PSK case
- id is the PSK identifier
- context is unique to the PSK and its allowed use.
  For example, it can be generated (out-of-band) as HKDF(PSK, “early data context”)

2) New Session Ticket

The NewSessionTicket message needs to indicate whether the server will accept 0-RTT,
and what ciphersuites it is willing to accept (e.g. pure PSK resumption vs only PSK-ECDHE).

I suggest the following modification to this message:
	struct {
         uint32 ticket_lifetime;
         opaque ticket<0..2^16-1>;
	 CipherSuite cipher_suites<2..2^16-2>;
	 EarlyDataType early_data_type
     	} NewSessionTicket;

        enum {
	  no_early_data_allowed(0),
          replayable_early_data_allowed (1),
          all_early_data_allowed(2),
          (65535)
       } EarlyDataType;

The interpretation of the early_data_type field is that the server is either:
(a) unwilling to accept 0-RTT (no_early_data_allowed), 
(b) willing to accept 0-RTT, but it has no replay cache (replayable_early_data_allowed),
(c) willing to accept 0-RTT and has a replay cache that it uses to prevent replay (all_early_data_allowed)

The client’s response to this ticket message should be to store it in its
session along with the “context” (session hash or derived from RMS),
the allowed cipher suites, and the early_data_indication.

When resuming with this ticket:
- the client should not send any 0-RTT data if no_early_data_allowed
- the client should only send replayable data if replayable_early_data_allowed (e.g. GET requests)
- the client can send any 0-RTT data if all_early_data_allowed, trusting the server to do the right thing.


A note on replay
----------------------

There has been much discussion on 0-RTT replay and here’s a quick summary of my understanding.
We already knew that an active attacker, or a lossy network, or an overzealous web browser could
and would cause 0-RTT (and even 1-RTT) data to be replayed to the server. This can already happen
in TLS 1.2, in QUIC, and so we accepted it as a given in TLS 1.3.

The new concerns on the mailing list (and in my TRON talk which was based on a ProVerif model) 
are that unlike TLS 1.2:
(a) even a passive attacker could replay 0-RTT data, long after the client has gone away,
(b) replaying authenticated 0-RTT data can be more damaging (whether authenticated with client cert or with a cookie), and
(c) by replaying 0-RTT data, the attacker can obtain encrypted 0.5-RTT data which opens up new attack vectors.

As a result of these new concerns, I would say that TLS 1.3 should recommend that all servers SHOULD
implement a replay cache, and those that cannot should clearly signal this to the client, so that the client
can adjust its 0-RTT use case and its expectations accordingly.

A note on authenticating the 0-RTT “context”
----------------------------------------------------------

When trying to figure out how to authenticate 0-RTT DH mode in an earlier draft, we came upon the
design of signing the Handshake Context that consists of the ClientHello + additional information from the previous handshake.
This construction prevents 0-RTT authentication from unknown key share attacks.

Even if we eliminate client certificate authentication from 0-RTT, this notion of “context" is still useful for two reasons:
(a) the application may use TokenBinding or some such protocol to authenticate 0-RTT data, and we need to understand what “channel binding” to provide for this case,
(b) in PSK resumption mode, since the handshake log does not contain much information that is specific to the previous connection, it would be more robust to add an explicit context.

If we accept the definition of “context” in the EarlyDataIndication extension, then we can use the hash of the ClientHello uniformly in all
0-RTT modes for deriving keys, and for deriving a channel binding for the application. Furthermore, we can safely introduce a PSK_ECDHE
mode where the server sends its Certificate and CertificateVerify and its signature is correctly bound to the PSK (via the “context” field).

Best regards,
Karthik