Re: [TLS] Server validation of a second ClientHello

[Eric Rescorla <[e-mail]>]

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

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

The current document does not mandate any particular implementation. If you
want to require a specific implementation then would need a new standards
track RFC.


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

There are an enormous number of ways in which TLS stacks can vary and
requiring indistinguishable behavior is not a goal of the TLS spec.



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

You're forbidden to change that value, so you'll only see interop failures
if the client is already nonconformant.

-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