On Friday 18 September 2015 13:24:33 Brian Smith wrote: > On Fri, Sep 18, 2015 at 4:36 AM, Hubert Kario <hka...@redhat.com> wrote: > > On Friday 18 September 2015 00:58:19 Martin Rex wrote: > > > Easier troubleshooting is IMO a sufficient rationale to justify > > > existence of the alert mechanism and a "SHOULD send the alert > > > before > > > closing the network connection". > > > > > > A "MUST send fatal alert" requirement, however, would be silly > > > (and > > > will be void in face of rfc2119 section 6 anyway). What would be > > > the semantics of such a requirement anyway? > > > > That's true only if you ignore the situation when TLS 1.4 or TLS 2.0 > > is deployed. > > > So yes, it's no a direct interoperability issue, but it will become > > one > > in the future. > > Given a *conformant* TLS 1.3 implementation, that kind of > interoperability problem could only happen if the TLS working group > specifically designed it to happen. In particular, a conformant TLS > 1.3 implementation must accept larger values of > ClientHello.client_version.
Given that there is no *conformant* TLS 1.2 implementation that is widely deployed[1], I won't hold my breath for there being many TLS1.3 ones either. We don't live in ideal world, lets build protocols that can handle breakage. Lets make specifications that have the sticks that we can hit developers with when they do wrong. 1 - NSS, SChannel and OpenSSL, all ignore some MUSTs in TLS1.2 -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, 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
