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. The same way as TLS protocol version in Client Hello > Right. We already have ample evidence that shows it is not reasonable for TLS 1.3 nor future versions can use ClientHello.client_version to signal the TLS version, due to broken non-TLS-1.3 implementations. But, unless a terrible mistake is made, whether or not a conformant TLS 1.3 implementation sends alert will not matter in those interactions. Cheers, Brian -- https://briansmith.org/
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
