Re: [TLS] Server validation of a second ClientHello

[Eric Rescorla <[e-mail]>]

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

> On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote:
> > 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.
>
> because you have already parsed, verified and sanity-checked the first
> hello,
> you already decided what kind of parameters will the connection use and
> you're
> expecting just the values that can change to change and ignoring
> everything
> else, thus not wasting cycles on verifying the extensions twice...
>

As MT says, we use a stateless design, and we don't necessarily verify the
entire
CH prior to sending HRR. For instance, it's not necessary to do certificate
selection
and hence not to look at signature_algorithms.



> so it's not clear to me why you'd ever want to use the second one
>

Well, clearly views differ on this, then.



> > 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.
>
> so you don't think this qualifies for Errata?
>

What Ben said.

-Ekr


>
> side note: it is actually possible to check if the 2nd CH has minimal
> changes
> in stateless HRR by replacing the extensions that can change with the
> hashes
> of their values and then storing the overall hash of CH message together
> with
> hashes of the extensions that can change. When receiving the 2nd CH, we
> can
> replace the extensions that can change with respective hash values and
> then
> check if the overall hash still matches. That translates to something like
> 4
> hashes, two positions and two flags (for padding and early_data). Only
> this
> much is necessary to check perfectly if the CH is unchanged. The only
> exception is pre_shared_key, but server behaviour with it is clearly
> defined -
> the server must use the values from 2nd CH as the selected_identity
> wouldn't
> match otherwise and binders couldn't be verified. With addition of one
> more
> hash in the cookie the server may easily ensure that the identity it
> planned
> to select remained in the CH. That's like 165 bytes when using
> non-truncated
> sha-256 hashes.
>
> --
> 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