> On Apr 18, 2018, at 11:54 AM, Daniel Margolis <[email protected]> wrote: > > How is it counter-intuitive? TLS 1.3 requires SNI, no?
No, TLS 1.3, *does not* require SNI. SNI is mandatory to implement, but NOT mandatory to use: https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.4.2.2 - The "server_name" [RFC6066] and "certificate_authorities" extensions are used to guide certificate selection. As servers MAY require the presence of the "server_name" extension, clients SHOULD send this extension, when applicable. [...] Additionally, all implementations MUST support use of the "server_name" extension with applications capable of using it. Servers MAY require clients to send a valid "server_name" extension. Servers requiring this extension SHOULD respond to a ClientHello lacking a "server_name" extension by terminating the connection with a "missing_extension" alert. Downgrading to TLS 1.2 with a deliberately unverifiable certificate seems rather drastic. In the world of SMTP, with SMTP server names determined indirectly and generally insecurely from MX records, it is not generally clear what name one would use in SNI, and many SMTP clients don't send it at all. Some authenticate servers against the nexthop domain (the envelope recipient domain), others might authenticate the MX host, or just do unauthenticated opportunistic TLS. This has worked acceptably well with TLS <= 1.2 -- Viktor. _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
