On Wed, Feb 13, 2019 at 10:23 AM Hubert Kario <hka...@redhat.com> wrote:
> On Wednesday, 13 February 2019 17:31:52 CET Eric Rescorla wrote: > > On Wed, Feb 13, 2019 at 7:39 AM Hubert Kario <hka...@redhat.com> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
