diff --git a/draft-ietf-tls-tls13.md b/draft-ietf-tls-tls13.md index 86def052e..4a8a63a39 100644 --- a/draft-ietf-tls-tls13.md +++ b/draft-ietf-tls-tls13.md @@ -1853,6 +1853,7 @@ in the first flight, the rest of the handshake uses the same messages. ClientHello + early_data + key_share* + (EncryptedExtensions) (Finished) (Application Data*) (end_of_early_data) --------> @@ -1897,7 +1898,7 @@ with the PSK. 2. There are no guarantees of non-replay between connections. Unless the server takes special measures outside those provided by TLS (See -{{replay-properties}}), the server has no guarantee that the same +{{replay-time}}), the server has no guarantee that the same 0-RTT data was not transmitted on multiple 0-RTT connections. This is especially relevant if the data is authenticated either with TLS client authentication or inside the application layer @@ -2244,6 +2245,7 @@ The extension format is: key_share(40), pre_shared_key(41), early_data(42), + ticket_age(43), (65535) } ExtensionType; @@ -2797,7 +2799,10 @@ following extensions: - The values of "key_share", "pre_shared_key", and "early_data", which MUST be as defined in this document. - + +In addition, it MUST validate that the ticket_age is within a small +tolerance of the time since the ticket was issued (see {{replay-time}}). + If any of these checks fail, the server MUST NOT respond with the extension and must discard all the remaining first flight data (thus falling back to 1-RTT). If the client attempts @@ -2813,20 +2818,71 @@ specified for all records when processing early data records. Specifically, decryption failure of any 0-RTT record following an accepted "early_data" extension MUST produce a fatal "bad_record_mac" alert as per {{record-payload-protection}}. +Implementations SHOULD determine the security parameters for the +1-RTT phase of the connection entirely before processing the EncryptedExtensions +and Finished, using those values solely to determine whether to +accept or reject 0-RTT data. [[TODO: How does the client behave if the indication is rejected.]] +##### Processing Order + +Clients are permitted to "stream" 0-RTT data until they +receive the server's Finished, only then sending the "end_of_early_data" +alert. In order to avoid deadlock, when accepting "early_data", +servers MUST process the client's Finished and then immediately +send the ServerHello, rather than waiting for the client's +"end_of_early_data" alert. -##### Replay Properties +##### Replay Properties {#replay-time} -As noted in {{zero-rtt-data}}, TLS does not provide any +As noted in {{zero-rtt-data}}, TLS provides only a limited inter-connection mechanism for replay protection for data sent by the -client in the first flight. As a special case, implementations where -the server configuration, is delivered out of band (as has been -proposed for DTLS-SRTP {{RFC5763}}), MAY use a unique server -configuration identifier for each connection, thus preventing -replay. Implementations are responsible for ensuring uniqueness of the -identifier in this case. +client in the first flight. + +The "ticket_age" extension sent by the client SHOULD be used by +servers to limit the time over which the first flight might be +replayed. A server can store the time at which it sends a server +configuration to a client, or encode the time in a ticket. Then, each +time it receives an early_data extension, it can check to see if the +value used by the client matches its expectations. + +The "ticket_age" value provided by the client will be shorter than the +actual time elapsed on the server by a single round trip time. This +difference is comprised of the delay in sending the NewSessionTicket +message to the client, plus the time taken to send the ClientHello to +the server. For this reason, a server SHOULD measure the round trip +time prior to sending the NewSessionTicket message and account for +that in the value it saves. + +There are several potential sources of error that make an exact +measurement of time difficult. Variations in client and server clocks +are likely to be minimal, outside of gross time corrections. Network +propagation delays are most likely causes of a mismatch in legitimate +values for elapsed time. Both the NewSessionTicket and ClientHello +messages might be retransmitted and therefore delayed, which might be +hidden by TCP. + +A small allowance for errors in clocks and variations in measurements +is advisable. However, any allowance also increases the opportunity +for replay. In this case, it is better to reject early data than to +risk greater exposure to replay attacks. + +#### Ticket Age + +%%% Key Exchange Messages + struct { + uint32 ticket_age; + } TicketAge; + +When the client sends the "early_data" extension, it MUST also send +a "ticket_age" extension in its EncryptedExtensions block. This value +contains the time elapsed since the client learned about the server +configuration that it is using, in milliseconds. This value can +be used by the server to limit the time over which early data can +be replayed. Note: because ticket lifetimes are restricted to a week, +32 bits is enough to represent any plausible age, even in milliseconds. + ### Server Parameters @@ -2834,26 +2890,35 @@ identifier in this case. When this message will be sent: -> The EncryptedExtensions message MUST be sent immediately after the +> In all handshakes, the server MUST send the +EncryptedExtensions message MUST be sent immediately after the ServerHello message. This is the first message that is encrypted -under keys derived from ES. +under keys derived from ES. If the client indicates "early_data" +in its ClientHello, it MUST also send EncryptedExtensions immediately +following the ClientHello and immediately prior to the Finished. Meaning of this message: -> The EncryptedExtensions message simply contains any extensions +> The EncryptedExtensions message contains any extensions which should be protected, i.e., any which are not needed to -establish the cryptographic context. The same extension types -MUST NOT appear in both the ServerHello and EncryptedExtensions. -If the same extension appears in both locations, the client -MUST rely only on the value in the EncryptedExtensions block. -All server-sent extensions other than those explicitly -listed in {{server-hello}} or designated in the IANA registry -MUST only appear in EncryptedExtensions. Extensions which -are designated to appear in ServerHello MUST NOT appear in -EncryptedExtensions. Clients MUST check EncryptedExtensions -for the presence of any forbidden extensions and if -any are found MUST terminate the handshake with -an "illegal_parameter" alert. +establish the cryptographic context. + +The same extension types MUST NOT appear in both the ServerHello and +EncryptedExtensions. If the same extension appears in both locations, +the client MUST rely only on the value in the EncryptedExtensions +block. All server-sent extensions other than those explicitly listed +in {{server-hello}} or designated in the IANA registry MUST only +appear in EncryptedExtensions. Extensions which are designated to +appear in ServerHello MUST NOT appear in EncryptedExtensions. Clients +MUST check EncryptedExtensions for the presence of any forbidden +extensions and if any are found MUST terminate the handshake with an +"illegal_parameter" alert. + +The client's EncryptedExtensions apply only to the early data +with which they appear. Servers MUST NOT use them to negotiate +the rest of the handshake. Only those extensions explicitly +designated as being included in 0-RTT Encrypted Extensions +in the IANA registry can be sent in the client's EncryptedExtensions. Structure of this message: @@ -3767,7 +3832,9 @@ is listed below: 1.3" column with the following four values: "Client", indicating that the server shall not send them. "Clear", indicating that they shall be in the ServerHello. "Encrypted", indicating that - they shall be in the EncryptedExtensions block, and "No" indicating + they shall be in the EncryptedExtensions block, "Early", indicating + that they shall be only in the client's 0-RTT EncryptedExtensions block, + and "No" indicating that they are not used in TLS 1.3. This column [shall be/has been] initially populated with the values in this document. IANA [shall update/has updated] this registry to add a @@ -3807,6 +3874,7 @@ is listed below: | key_share [[this document]] | Yes | Clear | | pre_shared_key [[this document]] | Yes | Clear | | early_data [[this document]] | Yes | Clear | +| ticket_age [[this document]] | Yes | Early | In addition, this document defines two new registries to be maintained