[zAy0LfpBZLC8mAC]

> Neither the text nor the address are necessarily "correct", and the text might be formally a nodename, a hostname, a domain name, a fully-qualified domain name, or a text representation of an IP address (which, again, is not necessarily correct).

Please don't make claims about standards that you haven't read. SNI supports only DNS FQDNs.

[quesera]

You are incorrrect.

That's not quite what the spec says, and furthermore it is not true in practice.

Giving you the benefit of the doubt, I reread the spec, and I tested in nginx.

Works fine.

[detaro]

What spec?

RFC6066 (https://tools.ietf.org/html/rfc6066#section-3) says "Currently, the only server names supported are DNS hostnames; however, this does not imply any dependency of TLS on DNS, and other name types may be added in the future (by an RFC that updates this document)." [snip] ""HostName" contains the fully qualified DNS hostname of the server, as understood by the client." [snip] "Literal IPv4 and IPv6 addresses are not permitted in "HostName"."

[quesera]

RFC6066, correct.

The "as understood by the client" is very important, apparently.

Furthermore, the name does not need to be in DNS. There is no single source of true DNS anyway (though of course the ~whole world uses the same root servers).

Try it. I just set up a remote server for "snitest", added the IP address to /etc/hosts only, generated a cert for that name only, and got the correct cert via SNI in a local browser.

The same process (minus /etc/hosts modification) also worked for a bare (textual representation of an) IP address.

[zAy0LfpBZLC8mAC]

> Furthermore, the name does not need to be in DNS. There is no single source of true DNS anyway (though of course the ~whole world uses the same root servers).

That is not "furthermore", that is what "as understood by the client" means.

> Try it. I just set up a remote server for "snitest", added the IP address to /etc/hosts only, generated a cert for that name only, and got the correct cert via SNI in a local browser.

That is a fully qualified DNS hostname, by definition. You told both your server that it was a DNS FQDN it should serve and your client that it was a DNS FQDN that it should request, and so they obviously were matched exactly as required by the standard. Whether DNS is involved in the resolution process is irrelevant, especially so given that the standard nowhere specifies the DNS root to use.

> The same process (minus /etc/hosts modification) also worked for a bare (textual representation of an) IP address.

What was the name type in the certificate? That sounds like a bug in the client, and possibly in the server as well.

[quesera]

Is your argument that a name can be a DNS FQDN even if it is not in DNS?

A non-DNS hostname can be treated as fully-qualified since there's no organizational structure to qualify it in.

> What was the name type in the certificate?

The CN? Is the IP address, as specified at cert generation.

> That sounds like a bug in the client, and possibly in the server as well.

Perhaps. I'm not a standards adjudicator.

Nevertheless, it works in the web we have. Tested in nginx, OpenSSL, curl, Firefox.

[zAy0LfpBZLC8mAC]

> Is your argument that a name can be a DNS FQDN even if it is not in DNS?

In the sense of the SNI spec, yes. It would be pointless to require the name to be "in DNS", for the simple reason that there is a potentially infinite number of DNS roots, and protocol standards naturally don't specify instances, only mechanism, so any TLS client could just implement a DNS server that uses the hosts file as its data source for a private DNS root and uses that for resolution, which would be indistinguishable from an implementation that simply skips the pointless encoding and decoding of DNS messages.

The point is to (a) distinguish host names from IP addresses, (b) require fully qualified names, (c) specify the syntax of the host names. Whether the names are actually in any DNS is irrelevant.

> A non-DNS hostname can be treated as fully-qualified since there's no organizational structure to qualify it in.

Sure, and that is fine. The point of the FQDN requirement is that if you send "foobar" as the SNI hostname, you cannot expect the server to match it to a certificate for "foobar.example.com". If both server and client agree on a namespace(/DNS root) where "foobar" is a fully qualified name, then you can expect everything to work just fine. It's not a requirement on how the name is to be verified, only a guarantee on how it may be transformed by protocol participants.

> The CN? Is the IP address, as specified at cert generation.

The CN is essentially deprecated, but matching an IP address in SNI against the CN should be fine. I am just not aware of any way to encode an IP address in SNI. If you had an alternate name IP address in the cert, matching an SNI host name against that would be a bug. If the browser actually accepted a certificate for an IP address when matching against a hostname, that would be a vulnerability.

> Nevertheless, it works in the web we have. Tested in nginx, OpenSSL, curl, Firefox.

Nah, if stuff that contradicts the standard happens, that means that there are things that the standard guarantees to work, but that are broken with the non-compliant implementation. Whether that buggy behaviour is useful to you in some way doesn't change that it's not "working" in any meaningful sense.

Oh, and if by OpenSSL you mean the command line tools: Yes, with those it does work correctly. If you specify the SNI name 1.2.3.4, that is the DNS hostname 1.2.3.4, which should indeed be correctly matched by the server against any certs for alternate DNS name 1.2.3.4, or possibly against certs for CN 1.2.3.4, but not certs for alternate name IP address 1.2.3.4.

[zAy0LfpBZLC8mAC]

What works fine that is not syntactically a fully qualified DNS hostname, and what could you even test about that?