looking for terminology recommendations concerning non-rooted FQDNs

> From: "Brian Reichert" <reichert@numachi.com>

[I believe this is Brian, then Mark: ]
> > > When I did my initial development with OpenSSL, I observed:
> > >
> > > - If I did not have the rooted domain name in the SAN, then any SSL
> > > client stack would fail the verification if a rooted domain name
> > > was used to connect to the SSL server.
> >
> > Well you have a broken SSL client app. If it is accepting non legal
> > hostnames it should be normalising them before passing them to the
> > ssl layer.
>
> From what little research I've done (only OpenSSL), the SSL client
> is relying on getaddrinfo(3) to do name resolution. In turn, I
> haven't found an implementation of getaddrinfo(3) that rejects
> rooted domain names as non-legal.

Yes, but that's not the question, Brian, assuming I understand the problem
as well as I think I do. The question is not how the client does the
name resolution on the client machine -- it's what it does with the domain
name it's looking up before doing the SSL interaction with the server side,
a process with which I'm not familiar enough to know if the client actually
send the host/domain name to the server end. Assuming it does -- and I
am -- the question is: should it take the dot off.

My understanding is this:

Unless you're doing client certificate verification (wherein the
server is making decisions about which clients attempting a
connection), all validation/verification is done by the client.

The SSL client retrieves the server's certificate, and the set of
values in the Subject and the Subject Alternative Name is compared
against the hostname/IP address used to initiate the process. This
comparison is (to my understanding) straight-forward (modulo UTF8
encodings, etc.).

The upshot (assuming I'm not totally off base here), is that other
than getaddrinfo(), nothing is acting on the semantics of the
supplied hostname (or IP address). They are 'just strings', and
are (essentially) compared as such.

From: "Brian Reichert" <reichert@numachi.com>

My understanding is this:

Unless you're doing client certificate verification (wherein the
server is making decisions about which clients attempting a
connection), all validation/verification is done by the client.

Right; my apologies; I know better than to post Before Coffee. :slight_smile:

The SSL client retrieves the server's certificate, and the set of
values in the Subject and the Subject Alternative Name is compared
against the hostname/IP address used to initiate the process. This
comparison is (to my understanding) straight-forward (modulo UTF8
encodings, etc.).

The upshot (assuming I'm not totally off base here), is that other
than getaddrinfo(), nothing is acting on the semantics of the
supplied hostname (or IP address). They are 'just strings', and
are (essentially) compared as such.

Right. And I'm asserting that that's wrong: the client side libraries
Really Ought To normalize that name before trying to compare it against
the retrieved certificate to see if it matches, which would relieve you
of having to have the altName with the trailing dot in such a cert.

The controlling standard *appears* to be RFC 2246, TLS v1.0. I'm doing
some work this morning, but that's up in a tab for coffee breaks; I'll
try to figure out what I think Dierks and Allen thought about this topic,
if anything, during the day.

Cheers,
-- jra

> The upshot (assuming I'm not totally off base here), is that other
> than getaddrinfo(), nothing is acting on the semantics of the
> supplied hostname (or IP address). They are 'just strings', and
> are (essentially) compared as such.

Right. And I'm asserting that that's wrong: the client side libraries
Really Ought To normalize that name before trying to compare it against
the retrieved certificate to see if it matches, which would relieve you
of having to have the altName with the trailing dot in such a cert.

I know for internal testing, I've had to introduce unqualified
hostnames in the CSR as well (e.g. 'testhost', instead of
'testhost.example.com'), to handle the case of the client not using
domain names at all (when framing queries). This illustrates that
there's not even an effort to synthesize a FQDN.

Who should implement the normalization logic? Not the SSL library,
certainly. That sounds like the bailiwick of the resolver library...

The controlling standard *appears* to be RFC 2246, TLS v1.0. I'm doing
some work this morning, but that's up in a tab for coffee breaks; I'll
try to figure out what I think Dierks and Allen thought about this topic,
if anything, during the day.

I look forward to the fruits of your research. :slight_smile:

getaddrinfo should not reject foo.blah.com. or foo.blah.com. However,
it will use the data… foo.blah.com will have the domain search strings
(if any) appended, so for example, if your search configuration is
"blah.com, example.com", then it will search for foo.blah.com.blah.com.,
foo.blah.com.example.com., and foo.blah.com. until it finds a match.

However, that's for the resolver library. In terms of matching the CN
in a certificate, this should always be FQDN and the trailing dot
should not be present. If OpenSSL (the command line tool) is passing
foo.blah.com. to the SSL functions and not just getaddrinfo(), then,
it is a bug.

Owen

When I did my initial development with OpenSSL, I observed:

- If I did not have the rooted domain name in the SAN, then any SSL
  client stack would fail the verification if a rooted domain name
  was used to connect to the SSL server.

Well you have a broken SSL client app. If it is accepting non legal
hostnames it should be normalising them before passing them to the ssl
layer.
From what little research I've done (only OpenSSL), the SSL client

is relying on getaddrinfo(3) to do name resolution. In turn, I
haven't found an implementation of getaddrinfo(3) that rejects
rooted domain names as non-legal.

getaddrinfo should not reject foo.blah.com. or foo.blah.com. However,
it will use the data� foo.blah.com will have the domain search strings
(if any) appended, so for example, if your search configuration is
"blah.com, example.com", then it will search for foo.blah.com.blah.com.,
foo.blah.com.example.com., and foo.blah.com. until it finds a match.

The lookup order should be foo.blah.com, foo.blah.com.blah.com, foo.blah.com.example.com ?

From: "Brian Reichert" <reichert@numachi.com>

> Right. And I'm asserting that that's wrong: the client side libraries
> Really Ought To normalize that name before trying to compare it against
> the retrieved certificate to see if it matches, which would relieve you
> of having to have the altName with the trailing dot in such a cert.

I know for internal testing, I've had to introduce unqualified
hostnames in the CSR as well (e.g. 'testhost', instead of
'testhost.example.com'), to handle the case of the client not using
domain names at all (when framing queries). This illustrates that
there's not even an effort to synthesize a FQDN.

And there probably shouldn't be, and yes, you will probably have to have
short names in there as altnames; there isn't -- and again, cannot be --
a rule for that; it's implementation dependent.

Who should implement the normalization logic? Not the SSL library,
certainly. That sounds like the bailiwick of the resolver library...

No, in fact, I think this is layer... 3 or 4, not 2; this *should*
be in the SSL library -- *you're not resolving this name*.

> The controlling standard *appears* to be RFC 2246, TLS v1.0. I'm
> doing
> some work this morning, but that's up in a tab for coffee breaks;
> I'll
> try to figure out what I think Dierks and Allen thought about this
> topic,
> if anything, during the day.

I look forward to the fruits of your research. :slight_smile:

Pomegranates. Martha Stewart taught me over the weekend how to get
the seeds out without ruining them.

Cheers,
-- jra

If I understood Brian correctly, his problem is that people/programs
are trying to retrieve things from, eg:

https://my.host.name./this/is/a/path

and the SSL library fails the certificate match if the cert doesn't contain
the absolute domain name as an altName -- because *the browser* (or whatever)
does not normalize before calling the library.

As I suggest in another thread, I think the SSL library probably ought to
be normalizing off that trailing dot itself, before trying to match the
string supplied to the names in the retrieved cert.

It sounds as if you might agree with me, at least in principle.

Cheers,
-- jra

I don't see any reason that the SSL library shouldn't normalize the
name and remove the trailing dot.

However, even if the SSL library does so, I see no valid reason that
would relieve the browser of the obligation to do so as well.

Be conservative in what you send (or pass to a library) and liberal
in what you accept.

Under that principle, the SSL library should accept either one and
normalize it. However, the browser should also normalize what it
passes to the SSL library.

Owen

If I understood Brian correctly, his problem is that people/programs
are trying to retrieve things from, eg:

https://my.host.name./this/is/a/path

and the SSL library fails the certificate match if the cert doesn't contain
the absolute domain name as an altName -- because *the browser* (or whatever)
does not normalize before calling the library.

I'd argue that if you have an absolute domain name, then that _is_
the 'normalized' form of the domain name; it's an unambigious
representation of the domain name. (Here, I'm treating the string
as a serialized data structure.)

Choosing to remove the notion of "this is rooted", and then asking
any (all?) other layers to handle the introduced ambiguity sounds
like setting yourself up for the issues that RFC 1535 was drawing
attention to.

Brian,

This may be a silly question, but what's your goal here? Your OP was about terminology, but the thread has gone down several different off-topic ratholes.

Doug

From: "Brian Reichert" <reichert@numachi.com>

> If I understood Brian correctly, his problem is that people/programs
> are trying to retrieve things from, eg:
>
> https://my.host.name./this/is/a/path
>
> and the SSL library fails the certificate match if the cert doesn't contain
> the absolute domain name as an altName -- because *the browser* (or
> whatever) does not normalize before calling the library.

I'd argue that if you have an absolute domain name, then that _is_
the 'normalized' form of the domain name; it's an unambigious
representation of the domain name. (Here, I'm treating the string
as a serialized data structure.)

I disagree, and happily, I can tell you exactly why.

Choosing to remove the notion of "this is rooted", and then asking
any (all?) other layers to handle the introduced ambiguity sounds
like setting yourself up for the issues that RFC 1535 was drawing
attention to.

The interface we're talking about here is an application on a machine
asking the SSL library "does the certificate which I have retrieved and
handed to you for processing match this domain name?"

*Since that certificate has [possibly] come from a different machine*,
the context in which that evaluation must be done seems necessarily to
be "over the wire/remote", and -- if you accept my earlier premise --

*it[1] is inherently absolute, no matter what it contains*.

Since that context exists, you can then safely strip off the trailing
dot inside the library before making said comparison.

This is not the same circumstance as being presented with a shortname,
where the actual IP connection/SSL retrieval was done based on the
resolver applying a search path: in this case there's no obvious
thing which the library could add, whereas it *is* obvious what you
should strip (and, I allege, why) in the absolute-name-provided case.

[1] The context of the evaluation, and by extension, the context of the
string you're handing the SSL library to do the match.

Cheers,
-- jra

Or maybe even above that.

RFC 5246 seems the currently controlling spec, and neither it nor
the Wikipedia article on this:

https://en.wikipedia.org/wiki/Transport_Layer_Security

actually says *what the client is supposed to do with the Server Certificate*
which 7.4.2 says the server will send; appendix D.2 explicitly punts that
question "upstairs"... but I'm not sure exactly to where, as I don't know
in detail how HTTPS connections are generally set up.

I suspect, though, that at this point, it leaves NANOG's domain.

Cheers,
-- jra

Brian,

This may be a silly question, but what's your goal here? Your OP was
about terminology, but the thread has gone down several different
off-topic ratholes.

That was indeed by original goal, and there have been a couple of
useful suggestions, and I thank this forum for all of the suggestions
and feedback.

I later mentioned why I was pursuing the terminology (use case
surrounding entries in a SAN), and there's some effort to consider
whether or not my issue is really a non-issue.

Which it might be.

> From: "Brian Reichert" <reichert@numachi.com>

[I believe this is Brian, then Mark: ]
> > > When I did my initial development with OpenSSL, I observed:
> > >
> > > - If I did not have the rooted domain name in the SAN, then any SSL
> > > client stack would fail the verification if a rooted domain name
> > > was used to connect to the SSL server.
> >
> > Well you have a broken SSL client app. If it is accepting non legal
> > hostnames it should be normalising them before passing them to the
> > ssl layer.
>
> From what little research I've done (only OpenSSL), the SSL client
> is relying on getaddrinfo(3) to do name resolution. In turn, I
> haven't found an implementation of getaddrinfo(3) that rejects
> rooted domain names as non-legal.

And getaddrinfo() returns the canonical name (ai_canonname) which
is the name found after searching, if any, and CNAMEs (DNAME) have
been followed. It doesn't have a period at the end unless there
is a implementation bug.

     struct addrinfo {
             int ai_flags; /* input flags */
             int ai_family; /* protocol family for socket */
             int ai_socktype; /* socket type */
             int ai_protocol; /* protocol for socket */
             socklen_t ai_addrlen; /* length of socket-address */
             struct sockaddr *ai_addr; /* socket-address for socket */
             char *ai_canonname; /* canonical name for service location */
             struct addrinfo *ai_next; /* pointer to next in list */
     };

Now http{s} clients and server administrators have misused CNAME
for years so ai_canonname is not as useful as it should be.
ai_canonname should match the expected name in the presented CERT.
As a result the http{s} client needs to do the normalisation including
search list processing. Yes there are lots of broken clients.

Yes, but that's not the question, Brian, assuming I understand the problem
as well as I think I do. The question is not how the client does the
name resolution on the client machine -- it's what it does with the domain
name it's looking up before doing the SSL interaction with the server side,
a process with which I'm not familiar enough to know if the client actually
send the host/domain name to the server end. Assuming it does -- and I
am -- the question is: should it take the dot off.

===

More formally: "is a host/domain name with a trailing dot *actually a
legal host name?

No. See RFC 952

> More formally: "is a host/domain name with a trailing dot *actually a
> legal host name?

No. See RFC 952

In the case of URIs, RFC 2396 (circa 1998) seems to allow for it,
if I read the ABNF for 'hostname' right in section 3.2.2.

But that's the only place I see it.

From: "Mark Andrews" <marka@isc.org>

> > From what little research I've done (only OpenSSL), the SSL client
> > is relying on getaddrinfo(3) to do name resolution. In turn, I
> > haven't found an implementation of getaddrinfo(3) that rejects
> > rooted domain names as non-legal.

And getaddrinfo() returns the canonical name (ai_canonname) which
is the name found after searching, if any, and CNAMEs (DNAME) have
been followed. It doesn't have a period at the end unless there
is a implementation bug.

struct addrinfo {
int ai_flags; /* input flags */
int ai_family; /* protocol family for socket */
int ai_socktype; /* socket type */
int ai_protocol; /* protocol for socket */
socklen_t ai_addrlen; /* length of socket-address */
struct sockaddr *ai_addr; /* socket-address for socket */
char *ai_canonname; /* canonical name for service location */
struct addrinfo *ai_next; /* pointer to next in list */
};

Now http{s} clients and server administrators have misused CNAME
for years so ai_canonname is not as useful as it should be.
ai_canonname should match the expected name in the presented CERT.
As a result the http{s} client needs to do the normalisation including
search list processing. Yes there are lots of broken clients.

Sure, but both of those were red herrings, as we weren't at that point
talking about DNS proper anymore, but on-machine interpretation of an
imported SSL cert against a hostname generated on-machine.

As I note here:

> Yes, but that's not the question, Brian, assuming I understand the problem
> as well as I think I do. The question is not how the client does the
> name resolution on the client machine -- it's what it does with the
> domain name it's looking up before doing the SSL interaction with the
> server side,
> a process with which I'm not familiar enough to know if the client
> actually
> send the host/domain name to the server end. Assuming it does -- and
> I am -- the question is: should it take the dot off.

:slight_smile:

> More formally: "is a host/domain name with a trailing dot *actually
> a legal host name?

No. See RFC 952

I think 952 is functionally obsolete, requireing a <24 char name length;
I would have expected citations, perhaps, to 1535.

Care to expand?

Cheers,
-- jra

Concur, unhappily. And at this point, we are *definitely* out-of-scope
for NANOG. :slight_smile:

Cheers,
-- jra

> From: "Mark Andrews" <marka@isc.org>

> > > From what little research I've done (only OpenSSL), the SSL client
> > > is relying on getaddrinfo(3) to do name resolution. In turn, I
> > > haven't found an implementation of getaddrinfo(3) that rejects
> > > rooted domain names as non-legal.
>
> And getaddrinfo() returns the canonical name (ai_canonname) which
> is the name found after searching, if any, and CNAMEs (DNAME) have
> been followed. It doesn't have a period at the end unless there
> is a implementation bug.
>
> struct addrinfo {
> int ai_flags; /* input flags */
> int ai_family; /* protocol family for socket */
> int ai_socktype; /* socket type */
> int ai_protocol; /* protocol for socket */
> socklen_t ai_addrlen; /* length of socket-address */
> struct sockaddr *ai_addr; /* socket-address for socket */
> char *ai_canonname; /* canonical name for service location */
> struct addrinfo *ai_next; /* pointer to next in list */
> };
>
> Now http{s} clients and server administrators have misused CNAME
> for years so ai_canonname is not as useful as it should be.
> ai_canonname should match the expected name in the presented CERT.
> As a result the http{s} client needs to do the normalisation including
> search list processing. Yes there are lots of broken clients.

Sure, but both of those were red herrings, as we weren't at that point
talking about DNS proper anymore, but on-machine interpretation of an
imported SSL cert against a hostname generated on-machine.

As I note here:

> > Yes, but that's not the question, Brian, assuming I understand the proble
m
> > as well as I think I do. The question is not how the client does the
> > name resolution on the client machine -- it's what it does with the
> > domain name it's looking up before doing the SSL interaction with the
> > server side,
> > a process with which I'm not familiar enough to know if the client
> > actually
> > send the host/domain name to the server end. Assuming it does -- and
> > I am -- the question is: should it take the dot off.

:slight_smile:

> > More formally: "is a host/domain name with a trailing dot *actually
> > a legal host name?
>
> No. See RFC 952

I think 952 is functionally obsolete, requireing a <24 char name length;
I would have expected citations, perhaps, to 1535.

Care to expand?

Ok. RFC 952 as modified by RFC 1123. This covers all legal hostnames
in use today including those that do not fit in the DNS. The DNS
supports hostnames up to 253 bytes (255 bytes in wire encoding).
RFC 1123 allow hostnames to go to 255 bytes. I'm deliberately
ignoring IDN's as they still need to map back into what is permitted
by RFC 952 as modified by RFC 1123.

RFC 1535 is NOT a STANDARD. Not all RFC are created equal.

getaddrinfo() is *independent* of the underlying name resolution
technology. The DNS, NIS, /etc/hosts LDAP all have the concepts
of canoical name and alias.

Mark

From: "Mark Andrews" <marka@isc.org>

> > No. See RFC 952
>
> I think 952 is functionally obsolete, requireing a <24 char name
> length;
> I would have expected citations, perhaps, to 1535.
>
> Care to expand?

Ok. RFC 952 as modified by RFC 1123. This covers all legal hostnames
in use today including those that do not fit in the DNS. The DNS
supports hostnames up to 253 bytes (255 bytes in wire encoding).
RFC 1123 allow hostnames to go to 255 bytes. I'm deliberately
ignoring IDN's as they still need to map back into what is permitted
by RFC 952 as modified by RFC 1123.

And except on length and first-digit-allowed, 1123 punts naming to 952
(which doesn't really say) and in 6.1, to 1034 and 1035. So I know what
my light night reading will be (unless Albitz, Liu, Mockapetris, or any
of the BIND team are around on the list :slight_smile:

RFC 1535 is NOT a STANDARD. Not all RFC are created equal.

Typo. 1035 (as updated by whatever is on-point, if anything).

And Mark: could you please trim your quoting a bit?

Cheers,
-- jra