Re: [TLS] Server validation of a second ClientHello

I concur with what I take to be MT's position here:

1. The client is clearly prohibited from changing most elements of the CH
(except for listed exceptions).
2. It's reasonable to check for and fail the handshake on any spec
violation except those where checking is explicitly forbidden (e.g., Must
Be Zero but Must be Ignored)
3. Nothing in the spec requires the server to check for this condition.

-Ekr

On Tue, Feb 12, 2019 at 4:53 AM Hubert Kario <hkario@redhat.com> wrote:

> On Monday, 11 February 2019 00:43:39 CET Martin Thomson wrote:
> > On Fri, Feb 8, 2019, at 23:53, Hubert Kario wrote:
> > > 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)
> >
> > Yeah, that's ridiculously large.  With quite a few extensions supported,
> and
> > many more unknown to us, the only way we might realistically ensure that
> > the ClientHello doesn't change is to save a hash snapshot at every
> boundary
> > where the cookie extension might be inserted or where an extension might
> be
> > changed.  SHA-2 has a fairly small state to capture, but that's still
> > nearly unbounded state.  With an amplification factor of up to 8, meaning
> > that it could be more efficient to send the client its entire ClientHello
> > in the cookie.
>
> I definitely won't claim that it is easy or straight-forward to do, I do
> claim
> that it is possible. Yes, sometimes it may mean that sending the literal
> CH in
> cookie may be more bandwidth efficient.
>
> And regarding the specific extension in question, to verify that it didn't
> change between Hello's it is only 2 bytes extra in cookie. If that is too
> much
> already, I don't think that stateless HRR is something we will see in
> implementations for years to come.
>
> --
> 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_______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>