Re: [TLS] Server validation of a second ClientHello

[Eric Rescorla <[e-mail]>]

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

> On Wednesday, 13 February 2019 17:31:52 CET Eric Rescorla wrote:
> > 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:
> > > > 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...
> > >
> > > so it's not clear to me why you'd ever want to use the second one
> >
> > Well, clearly views differ on this, then.
>
> yes, that was my point, and the reason why I'd like to see clarification
> or
> agreement on expected behaviour
>

> so if my understanding is correct, to do that, we would need to agree on a
> new
> RFC that clarifies such issues
>

I'm not so sure.

- I don't think that the specification ought to require checking and/or not
checking.
- I don't think it should require using the first CH, and unsure whether we
should require use of the second CH, but it doesn't sound like there's
consensus on that.

-Ekr



-- 
> 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