Hannes: The ID indicates that the two ClientHellos must be identical except for the fields explicitly listed. If you strongly disagree, then you should request a change to the ID. I understand your opinions on the matter; but as written, the ID requires those fields extensions to be the same. Here is the text in question, emphasis mine:
4.1.2<https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-4.1.2>. Client Hello When a client first connects to a server, it is REQUIRED to send the ClientHello as its first message. The client will also send a ClientHello when the server has responded to its ClientHello with a HelloRetryRequest. In that case, the client MUST send the same ClientHello (without modification) except: - If a "key_share" extension was supplied in the HelloRetryRequest, replacing the list of shares with a list containing a single KeyShareEntry from the indicated group. - Removing the "early_data" extension (Section 4.2.9<https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-4.2.9>) if one was present. Early data is not permitted after HelloRetryRequest. - Including a "cookie" extension if one was provided in the HelloRetryRequest. - Updating the "pre_shared_key" extension if present by recomputing the "obfuscated_ticket_age" and binder values and (optionally) removing any PSKs which are incompatible with the server's indicated cipher suite. To avoid DOS and maintenance of state, the server should not maintain any of this information (except, perhaps indirectly via the cookie) if an HRR is returned. Thus the ClientHello is sent with all the information provided again. Yes, it’s a slight waste of bandwidth, but I’d rather use bandwidth that fleets away like time (use it or lose it), than memory in my device. This also permits multiple methods of implementation of the initial connection if all the information is provided again. -- -Todd Short // tsh...@akamai.com<mailto:tsh...@akamai.com> // "One if by land, two if by sea, three if by the Internet." On Aug 29, 2017, at 7:20 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net<mailto:hannes.tschofe...@gmx.net>> wrote: Hi Noah, Todd, Ilari, the HRR is used for two purposes, namely * to report an error (with the key shares), and * for DoS protection. In both cases it feels excessive to require that the two ClientHellos are the same (with some minor exceptions). I see this as particularly problematic for the use with DTLS since with connectionless transport protocols the use of the HRR is obviously common and we are essentially wasting bytes on the wire for no good reason(with every handshake). For the return-routability check there will be a cookie in the HRR and the RR check is useful primarily for connectionless transports. Re-transmitting the same information twice in this case is of doubtful value since (a) either the cookie contains the necessary info already or (b) the second ClientHello carries the relevant information. Does this make sense? Ciao Hannes On 08/22/2017 10:13 PM, Ilari Liusvaara wrote: On Tue, Aug 22, 2017 at 05:50:49PM +0000, Noah Robbin wrote: Hello Todd! I also did not see a reason why the random values had to be the same but the language does mandate it. I really do not think there is any technical or security reason why the randoms have to be the same. After all, TLS 1.3 does not directly use the randoms anywhere (they only affect things indirectly via hashes of the handshake). You make a good argument for not altering the padding on the second ClientHello. I read that argument as "TLS 1.3 implementations should not need padding". I took a look at struct ClientHello and the extensions list: There are technical reasons for not altering (the client has no idea what the heck server did with these): - server_name - max_fragment_length - status_request - signature_algorithms - use_srtp - heartbeat - application_layer_protocol_negotiation - signed_certificate_timestamp - client_certificate_type - server_certificate_type - psk_key_exchange_modes (due to side-effects) - certificate_authorities - post_handshake_auth The following are explicitly listed as to be altered/deleted: - key_share - pre_shared_key - early_data - cookie The following do not negotiate state: - <random> - padding The following can't appear in ClientHello: - oid_filters The following client gains information about in HRR: - <ciphersuites> - supported_groups (partially if key_share was not present). - supported_versions (the client knows what server selected). However the last group seems to be kind of things that are rather questionable to prune (might be okay, but those make me wary). Also, I came accross one edge case: What if client discovers that all tickets in pre_shared_key are incompatible? The definition does not allow 0 tickets, so choices are: 1) Leave all the tickets (which is not going to work) in. 2) Leave one ticket (which is not going to work) in. 3) Strip the entiere extension. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
