Re: [TLS] Server validation of a second ClientHello

[Eric Rescorla <[e-mail]>]

On Wed, Feb 13, 2019 at 4:12 AM Hubert Kario <[e-mail]> wrote:

> On Wednesday, 13 February 2019 01:31:41 CET Eric Rescorla wrote:
> > 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.
>
> and what about values that technically can't change (as you noted
> yourself)
> but they do change and the server does use them?
>
> you are not suggesting that which value will be used (from first or second
> CH), or if the connection will be aborted, to be implementation dependant
> *by design* , do you?
>

I'n not sure I understand your question, but I'll try to answer what I
think it says.

1. I do think that whether you continue the connection or abort it is an
implementation decision and I think that the way the spec is written says
that.
2. I think the spec leaves open whether you should use the first or second
values, but I think implementations should use the second value. It's not
clear why one would want to use the first.

To my knowledge, there was never a WG discussion about this exact question,
so we only have the spec to guide us. Were we pre-publication I would have
advocated for (a) leaving open whether to abort and (b) requiring you to
use the second value.

-Ekr






> > -Ekr
> >
> > On Tue, Feb 12, 2019 at 4:53 AM Hubert Kario <[e-mail]> 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/tls
>
>
> --
> 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