On Wednesday, 13 February 2019 20:01:10 CET Eric Rescorla wrote: > 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 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
