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

From: Hubert Kario <[email-masked]>
Date: Mon, 04 Sep 2017 18:41:00 +0200

On Tuesday, 29 August 2017 13:20:33 CEST Hannes Tschofenig 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?

Yes, though different Client Hello's can make the server select different set 
of algorithms (for example see Google selecting Chacha20 and AES-128-GCM over 
any else, but allowing the client to dictate which is actually negotiated if 
both are advertised). The second hello after modifications can cause the 
algorithm to select different values, despite HRR committing to specific set. 
Obviously that would be bad

Second thing is that if the second Client Hello is supposed to be identical to 
first one with few exceptions, the server does not need to parse or verify it 
fully before responding with Server Hello. 

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 4 Sep 2017 23:59:37 +0300

On Thu, Aug 31, 2017 at 09:50:07AM +1000, Martin Thomson wrote:
> On 30 August 2017 at 22:57, Ilari Liusvaara <[email-masked]> wrote:
> > However, I identified a new category of extensions that I didn't notice
> > before: Dependent on altered extensions. There are no such standardized
> > extensions, but there is at least one proposal (in WG draft stage).
> 
> Is it possible that you could help us by sharing which one?

early_token_binding from  draft-ietf-tokbind-tls13-0rtt

However, looks like in this case, the server advertises support for
this in an NST extension, so at least it doesn't get thrown to random
servers.

Thinking about this more, it seems that any field or extension that
could be different across retry falls into one of three categories:

1) Something related to 0-RTT.
2) Something "feral": These things basically do not play by the normal
   rules[1].
3) Something that does not actually negotiate state[2].

Altering anything else will probably provoke Undefined Behavior due to
unknown state commitments.

[1] E.g., anything that goes into HelloRetryRequest or ServerHello,
and supported_versions.

[2] E.g. (Random), Padding.

-Ilari