Re: [TLS] What counts as the same ClientHello?

["Short, Todd" <[e-mail]>]

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
// [e-mail]<mailto:[e-mail]>
// "One if by land, two if by sea, three if by the Internet."

On Aug 29, 2017, at 7:20 AM, Hannes Tschofenig <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tls


_______________________________________________
TLS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tls