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

[Karthik Bhargavan <[e-mail]>]

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

Good question. For 0-RTT, multiple PSK identities make no sense, 
because we can only use one of these for the 0-RTT key derivation.

Are there cases where the client wants to advertise multiple PSK identities
for 1-RTT? If so, we could retain the pre_shared_key extension specifically
for the 1-RTT PSK case, and disregard it for 0-RTT.

Best,
Karthik

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