On Wed, Feb 13, 2019 at 11:37 AM Hubert Kario <hka...@redhat.com> wrote:
> 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? > 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
