Hello! I have a question regarding a paragraph in the definition of SNI in RFC 3546. Citing: > Literal IPv4 and IPv6 addresses are not permitted in "HostName".
As far as I understand, the HostName field is used by the (web) server when deciding what certificate to send based on the ClientHello. Let's say, for backwards compatibility with older clients that do not support SNI, that the server will always respond with domain.example TLS certificate when SNI is not present. The server, however, also has a specific certificate for use when the client connects directly to the IP address (in case of HTTPS that would for example be a request for https://192.0.2.1/). Using the current specifications and configurations there is no way for a client to get the correct certificate for 192.0.2.1, because it can't signal to the server that it's connecting directly to an IP address. This sounds like a limitation to me. Is there any way for a server to differentiate between a client that does not support SNI and connects to domain.example and a client that supports SNI but connects to 192.0.2.1? What issues would be created if the above-mentioned paragraph was removed and the definition of HostName would be changed to allow FQDNs AND IP addresses? What is the reasoning behind limiting HostName field only to FQDNs? If allowing HostName would break something, would it be possible to add another NameType, IPAddress, that would support signaling IP addresses to the server? A similar issue was already discussed in quic-issues@ietf on 2020-01-07. Thanks! -- Anton Luka Šijanec <an...@sijanec.eu> _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
