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 -- 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
