Re: [TLS] Server validation of a second ClientHello

[Hubert Kario <[e-mail]>]

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