Re: [TLS] Server validation of a second ClientHello

[Hubert Kario <[e-mail]>]

On Wednesday, 13 February 2019 20:01:10 CET Eric Rescorla wrote:
> 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 said "I'd like", yes, I am aware that not everybody shares my views on those 
topics, but *if* we reach a conclusion and decide to update/clarify RFC 8446, 
it would require publishing a new RFC (depending on intrusiveness of it, it 
may be just "Informational" or it may need to be "Standards Track", with 
everything that it entails), wouldn't it?
 
> - 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.

it all depends on your threat model, if leaking information which kind of 
implementation you are running is useful information to the attacker, then 
having multiple implementations that are indistinguishable on protocol level 
may be very desirable

and in this specific example of record_size_limit, lack of agreement over 
extension from which Client Hello takes precedence will easily lead to 
interoperability failures

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