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

[Ilari Liusvaara <[e-mail]>]

On Fri, Mar 25, 2016 at 10:29:06AM +0100, Karthik Bhargavan wrote:
> 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;

You mean combining the 0-RTT aspects of pre_shared_key extension with
early_data? Because I don't think this type of structure can present what
PSK extension presents (e.g. multiple candidate PSK identities).
 
> In the semi-static DH case:
> - id is the configuration id
> - context is the hash of the ServerConfiguration + Server Certificate + CertificateRequest

This would close the loop between static key and the handshake (this
loop being open in previous versions creates some "excitement" (not a
good thing)).

Also, is this hash also used to bind the configuration, identity and
possible certificate request to 0-RTT keys? ServerConfiguration and
CertificateRequest are not problematic to reconstruct from small space,
but Certificate message can be good bit larger...

Ah, later it looks like these could then be dropped form 0-RTT key
derivation then...

> 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”)

The first would break symmetry between resumption and PSK. The second
would be symmetric with HKDF(PSK, “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”)

Seems reasonable way to generate the 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)

(b) vs (c) don't affect the next handshake except if 0-RTT data is sent
or not?

(I ask, because early_data_type with 0rtt auth does affect next handshake
in a way that is not signaled there, making it look horrifying to implement,
at least if one wants to enforce strict state machine behaviour).
 
> 
> 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.

It also looks to protect the _main_ TLS handshake from unknown key share
attacks when using 0-RTT DH mode.

> Even if we eliminate client certificate authentication from 0-RTT,
> this notion of “context" is still useful for two reasons:

Also, lacking 0-RTT certificate auth would be useful to deflect the
headlines if flaw in scheme is discovered (the flaw would then be
blamed on $PROTOCOL, not TLS). :-)

More seriously, if I was pick one aspect of current TLS 1.3
implmentability that terrifies me the most, it would be 0-RTT cert.
auth, by far.

When writing code doing state-machine handshake sequencing on TLS 1.2
and 1.3, by far the source of most expletives is either:

1) Some crazyness TLS 1.2 does with resumption (when session tickets
   are involved).
2) TLS 1.3 0-RTT cert auth (would really love to rip that code out).

> (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).

Yeah. Would solve a lot of problems with the current design.


-Ilari