[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.

[quesera]

> Whether that buggy behaviour is useful to you in some way doesn't change that it's not "working" in any meaningful sense.

I sense that you mean "working" as according to spec. I mean "working" as in practice. In my line of work, the latter is the only meaningful sense.

FWIW, this is not new behaviour, it has worked for at least a decade in various applications.

And yes, OpenSSL the command line tools. I'm not sure what you're talking about though, I've never seen a cert tied to an IP address. What representation would be encoded? My original assertion does not require any such thing.

I'm really not sure what we are disagreeing about any more. If you go back to my original comment, I don't think you'll find it controversial.

[zAy0LfpBZLC8mAC]

> I sense that you mean "working" as according to spec. I mean "working" as in practice. In my line of work, the latter is the only meaningful sense.

The idea that something that isn't working according to spec is supposedly working in practice is almost always an illusion.

> FWIW, this is not new behaviour, it has worked for at least a decade in various applications.

Well, yeah, buggy software is nothing new, that's true.

> And yes, OpenSSL the command line tools. I'm not sure what you're talking about though, I've never seen a cert tied to an IP address. What representation would be encoded?

You could put it in dotted-quad syntax into the CN field of the DN of the certificate's subject (I'm not sure that was ever explicitly allowed, but that was commonly implemented and that stuff is a mess anyhow, which is part of why alternative names were invented--and, as I mentioned, the CN is deprecated and at least Chrome nowadays ignores it unconditionally). The modern, correct way to encode an IP address as the subject of an X.509 certificate is in a subject alternative name field of type iPAddress, as specified here, 5th paragraph:

https://tools.ietf.org/html/rfc5280#page-36

Really, it's probably a stupid idea to have certificates for IP addresses, which is probably the reason why SNI does not support IP addresses ... but PKIX does nevertheless specify certificates for IP addresses.

> I'm really not sure what we are disagreeing about any more. If you go back to my original comment, I don't think you'll find it controversial.

Your claim that you could specify an IP address in SNI is still wrong. As for the other options, it depends on the exact definitions of those terms, they are probably partially wrong. You can not have anything but a fully qualified DNS hostname in SNI, by definition. Whatever you put into that field is by spec to be interpreted by the server as a DNS FQDN, as is the matching SAN field in candidate certificates, and the client must not cast an IP address specified by the user to be reinterpreted as a host name (or else, the server might respond with the certificate for DNS:*.4 when the user has requested https://1.2.3.4/, instead of the default certificate for IP:1.2.3.4 that would be returned when no SNI is present, thus leading to a connection failure even though the spec guarantees that the connection will work).

[quesera]

> The idea that something that isn't working according to spec is supposedly working in practice is almost always an illusion.

They're obviously different things. The what that is working is not necessarily the what that the spec writers intended or imagined.

I work in network and application security. A lot of what "works" flies in the face of your definition, and I don't find your definition useful outside of meeting rooms.

> Your claim that you could specify an IP address in SNI is still wrong.

I never claimed that. I claimed that you could specify the textual representation of an IP address, of which dotted quad is the most common and the only form I've tested. You have agreed with this, so I won't repeat myself.

At the very outset, my point was that the definitions of these words are very context-sensitive. A nodename, a hostname, a domain name, a fully-qualified domain name, a text representation of an IP address. They have overlapping common meanings, but all are functional, working names for use in SNI, as understood by standard tools of internet technology.

Your argument seems to be that any name that works in SNI is by definition a DNS FQDN, because the SNI spec says that only DNS FQDNs work.

But that is clearly not correct in any other context. "snitest" in /etc/hosts (or NIS etc!) is not a DNS FQDN. "8.8.8.8" is not a DNS FQDN. Both work as names in SNI.

[zAy0LfpBZLC8mAC]

> They're obviously different things. The what that is working is not necessarily the what that the spec writers intended or imagined.

But the what is all that matters. Without a what to ask the question "does it work?" about, there is no question to ask.

For any specification, you can create a derived but incompatible specification, either implicitly or explicitly, and an implementation of that derived specification certainly works. But it works as an implementation of that derived specification, not as an implementation of the original specification, and a component implementing the derived specification won't work in the general case when interoperating with a component implementing the original specification.

Also, for any given implementation it is possible to write a spec that it conforms to, so it's trivially true that any piece of software works in the sense that it conforms to some (potential) specification.

The point of specifications is not to declare what is the only possible way to do things, but to create a convention that allows interoperability. Stuff that doesn't work according to spec fails that goal, so it only works in the sense that anything that does something does something, and possibly something useful.

> I work in network and application security. A lot of what "works" flies in the face of your definition, and I don't find your definition useful outside of meeting rooms.

Nope, especially with regards to security, anything that "works in practice", but doesn't work according to spec, has a pretty decent chance of being a vulnerability.

> I never claimed that. I claimed that you could specify the textual representation of an IP address, of which dotted quad is the most common and the only form I've tested. You have agreed with this, so I won't repeat myself.

No, you can't. You can put a string into the SNI hostname field that is an element of the "dotted quad IPv4 address representation" language. But that is by definition not the textual representation of an IP address, but the textual representation of a hostname consisting of just digits and dots. The fact that you could potentially type-pun the representation into a context where it would be interpreted as an IP address does not change that it is not in fact representing an IP address. What a (formal) language means is defined by the specification of the language, not by the specification of any language that happens to contain a given string as an element.

When a database table has a field "first name", you can not store last names in it. It's irrelevant that you can use the field to store strings in it that could be parsed as last names--the fact that they are stored in the first name field makes them first names by definition.

When a database table has a field "phone number", you can not store ZIP codes in it. It's irrelevant that you can use the field to store strings in it that could be parsed as ZIP codes--the fact that they are stored in the phone number field makes them phone numbers by definition.

When a protocol message has a field "DNS hostname", you can not store IP addresses in it. It's irrelevant that you can use the field to store strings in it that could be parsed as IP addresses--the fact that they are stored in the DNS hostname field makes them DNS hostnames by definition.

Being confused about this is the root of multiple classes of vulnerabilities (language injections (SQL injection, XSS, shell injection, header injection), string termination vulnerabilities).

> At the very outset, my point was that the definitions of these words are very context-sensitive. A nodename, a hostname, a domain name, a fully-qualified domain name, a text representation of an IP address. They have overlapping common meanings,

Yes.

> but all are functional, working names for use in SNI, as understood by standard tools of internet technology.

No. Or, if they are, those tools are vulnerable.

> Your argument seems to be that any name that works in SNI is by definition a DNS FQDN, because the SNI spec says that only DNS FQDNs work.

You are having it all backwards. This is not about "what works", but about what it is defined to be. The definition of the protocol says that whatever you find in that field of the protocol message is defined to be a DNS FQDN. It doesn't matter what the sender secretly intended--the definition of SNI says that it is a DNS FQDN. If the sender intended the content of the field to be interpreted differently, they weren't implementing SNI.

> "snitest" in /etc/hosts (or NIS etc!) is not a DNS FQDN.

As I already explained, it is, in that the SNI spec doesn't care about the data source. You could trivially create a DNS root that had a TLD "snitest.", and under that DNS root, "snitest" would be a valid DNS FQDN.

> "8.8.8.8" is not a DNS FQDN.

Yes, it is. Just don't confuse it with the IP address "8.8.8.8". In the global DNS root, the TLD "8." does not exist, therefore, it doesn't exist, but it is a valid DNS hostname in the SNI hostname field.

> Both work as names in SNI.

Yes, of course they do. But IP addresses don't.

[quesera]

As an aside, is there a name for this purposeful perspective of strict literalism?

I say "purposeful" because -- while you're obviously knowledgeable about the subject matter -- it can't have failed to occur to you that this approach cannot succeed outside of a very structured context.

(Discussion of whether our conversation was within or without that context omitted, though it might have been the only important discussion possible)

Is this a subcategory of the formal language / langsec efforts? Just standard standards-writing practice? Something else?

[quesera]

Your literalism defeats you.

Of course you can store first names in a last name field. You can even choose to invert the label-semantic relationship between the two fields in your code. If "Bob" is stored in last_name, the data does not semantically become something it is not just because someone mislabeled it. It's a first name, no matter who wants to call it what.

"8.8.8.8" is not a DNS FQDN. Of course it could be, but it is not, in current practice. If you think of it as a DNS FQDN, you cannot assume it to have any relationship to IP address 8.8.8.8, which in all resolver libraries, it does. So it is not a DNS FQDN, and in fact is not even looked up when supplied. It is very precisely only ever used as a textual representation of an IP address, in dotted quad format. The direct representation of an IP address could not even be posted here. So it is as close and most familiar as we can get to an IP address. And I was always careful to qualify my comments that it was a textual representation of an IP address. Because I know the difference!

You also know that it is possible for "snitest" (or, more precisely, "snitest.") to be a DNS FQDN. But it almost never is. In practice, it is going to be a nodename, and it might not even be looked up in DNS. It's a token, a name, representing the final form of the query made by the client, that resulted in a returned address. And that is what I said all along.

The SNI spec does not get to redefine "IP address (textual representation of)" and "nodename" outside of its own context.

You could have been correct if you said, at the beginning, that while it might be a nodename or an IP address (text representation) in all ordinary contexts, the SNI spec defines anything that results in a valid mapping to an IP address as a "DNS FQDN". And isn't that interesting and not particularly useful? It could also call them "turtles", with equal usefulness.

But instead you accused me of not having read the spec, and you proclaimed that SNI only works with turtles.

You're wrong on both accounts. And we disagree about the definition of "working". Security exploits work. There is no deep epistemological problem created by the fact that the word is given meaning by its context.

Nodenames work in SNI. And textual representations of IP addresses work in SNI. Which is exactly what I wrote in my initial comment.

Since we can't agree on fundamental definitions, I don't think we're going to understand each other. I stand by my initial assertions.