Re: [TLS] Server validation of a second ClientHello

[Hubert Kario <[e-mail]>]

On Friday, 8 February 2019 04:31:18 CET Martin Thomson wrote:
> TLS 1.3 is pretty firm about what you can change in a second ClientHello. 
> It lists a small set of allowed changes to extensions (cookie, PSK binder,
> key shares, early data, and padding).  For the rest it says that nothing
> can change.  So clearly a client is in the wrong if it changes, adds, or
> removes an extension that isn't on this list.
> 
> The first question is whether a server should be required to check that only
> permitted changes are made to a second ClientHello.

given need for GREASE and two dozen flags across OpenSSL history for 
workarounds for bugs in different implementations, the lesson seems to be that 
the receiving side should be as strict as it can (within protocol confines) or 
we risk making the non-conforming behaviour common
 
> The second question is - if the server is not required to check for
> consistency - which ClientHello the server uses.
> 
> The third question is - if we allow checking at all - what the consistency
> check looks like.
> 
> My position is that the check cannot be mandatory, but we should allow
> servers to check.  One feature that we put significant effort into
> supporting was the notion of a stateless HelloRetryRequest, which I believe
> to be incompatible with checking (or at best extraordinately inconvenient).

"extraordinarily inconvenient" is description of the process of implementing 
any crypto and cryptographic protocols properly...
 
> With that answer in mind, if the second ClientHello might differ, I assert
> that the server uses that.  Hubert observes that this behaviour is not
> specified at all, which is entirely true.  I think that using the first
> ClientHello would be nonsensical, because the server needs to use the
> second ClientHello for those extensions that can change, like key share.

And I say that when you have already parsed, verified and sanity-checked the 
first set of extensions, it is much saner to reuse that work and only update 
the values that can change and ignore all other extensions...

There are multiple ways to look at this, and given that the standard is very 
firm that the 2nd CH needs to be as similar to the first one as possible, it 
is thus silent on which takes precedence in case they differ in general, 
because they can't.
 
> If we require or allow checking - and I think that we should definitely
> allow a check - the details of the conditions under which a check might
> fail aren't completely obvious for new extensions.  A new extension might
> be defined that has special handling in HelloRetryRequest, so it might be
> reasonable to allow new extensions to be changed.

yes, and we already had discussion on this ML about this: if the extension 
needs to change (based on protocol definition), the server MUST include it in 
HRR to signal to client, "yes, I do know about it, you can update it" and 
client MUST NOT change it otherwise
 
> The simplest thing here seems to be a prohibition on checking unknown
> extensions for consistency between ClientHello1 and ClientHello2.

that's definitely too harsh

> A final observation about checking extensions: it's not clear that we
> require consistent extension ordering.

the reordering is not in the list of allowed changes listed by the RFC

> If the key share extension changes,
> can it be reordered?

no

> Can unchanged extensions be reordered? 

no

> Clearly
> neither results in a semantic change, but if a server that is required to
> check, might need to aggressively compress information about the first
> ClientHello in order to comply and extension ordering is an obvious thing
> to erase to save space in the cookie.

the cookie can be up to 2^16 bytes long, even if client sends all 50 
extensions and spaces them with unknown extensions between, that's at most 20 
bytes per extension = 1000 bytes total extra space needed in cookie (32 bytes 
and 1600 bytes if you want to be very conservative)

and that's the excessive case, in usual case the server will not have to deal 
with more than half a dozen unknown extensions
-- 
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