> 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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
