Re: [Uta] Consensus call for proposed changes to draft-ietf-uta-rfc6125bis-10

[Viktor Dukhovni <[e-mail]>]

On Tue, Feb 07, 2023 at 07:31:56PM -0700, Peter Saint-Andre wrote:

> > So I think a better example is to either use the term "delegated"
> > when it really talks about DNS delegation, OR, you use a different
> > term but have an example where you can have:
> > 
> > - IMAP server: imap.example.se.
> > - MX target: mx.example.net.
> > - Email domain: example.com.
> 
> Although you might be right that "delegated domain" is less than
> ideal, it's the term we used in RFC 6125. As a result, a number of
> specifications that cite RFC 6125 also use the term, so it seems
> inadvisable to change terminology now.
> 
> The original idea was not DNS delegation at the nameserver level, but 
> service delegation at the application level such as one finds in this 
> document (e.g., in order to retrieve email for addresses at example.net, 
> one configures one's email client to connect to the server at 
> imap.example.net).
> 
> At the least, it seems reasonable for us to explain this in more detail 
> so that the reader doesn't confuse this perhaps bespoke notion of 
> service delegation with the perhaps more established notion of DNS 
> delegation.

Yes, a brief blurb clarifying the distinction would be helpful.

> I don't see why not. If DNS SRV records had existed from the beginning 
> of time, it seems that email protocols would have used SRV rather than 
> MX, right?

Perhaps so, though consequently ISP's would later have had a rather
difficult time blocking "port 25" from consumer IP pools, for better or
worse depending on your perspective...

> > What is then the difference or similarity between an MX related
> > derivation of one domain name from another and an SRV related
> > derivation?
> 
> It seems to me that they are functionally equivalent. But I am not a DNS 
> expert or email expert, so (leaving aside various nuances) I might be 
> missing some essential difference.

They are equivalent modulo substantially more complexity in the SRV
case, because of weights in addition to priorities and variable
per-target port numbers.

> > I presume you also include domain names that one at a time is
> > created using a search list construction in a DNS stub resolver? 

Search lists should be out of scope.  In the context of certificates
they are irrelevant.  They play a role only in IP address resolution.
Certificate matching happens against the original input hostname
"as-is", whether it is an FQDN or some library performs unspeakable
acts to turn it into one.

Perhaps in some future use-case some application will trust DNSSEC
sufficiently to take an FQDN alias (CNAME LHS) and replace it with its
DNSSEC-validated FQDN target, and use that for certificate name checks
instead...  Oh wait, that's what RFC767[12] DANE does when the target
has TLSA records (I need to have words with the culprit who wrote that
text... :-).  Regardless, this is still not related to name fragment
prefixes and search lists, those are out of scope.

> If I understand you correctly, I would say that we have not had a
> theory about how domain names are created (e.g., using a suffix search
> list).  And it's not clear to me that we need to have such a theory
> here.

+1.  Silence is golden.

> >>     1.  A "traditional domain name", i.e., a FQDN that conforms to
> >>         "preferred name syntax" as described in Section 3.5 of
> >>         [DNS-CONCEPTS] and for which all of its labels are "LDH labels"
> >>         as described in [IDNA-DEFS].  Informally, such labels are
> >>         constrained to [US-ASCII] letters, digits, and the hyphen, with
> >>         the hyphen prohibited in the first character position.
> >>         Additional qualifications apply (refer to the above-referenced
> >>         specifications for details), but they are not relevant here.
> >>
> >>     2.  An "internationalized domain name", i.e., a DNS domain name that
> >>         includes at least one label containing appropriately encoded
> >>         Unicode code points outside the traditional US-ASCII range and
> >>         conforming to the processing and validity checks specified for
> >>         "IDNA2008" in [IDNA-DEFS] and the associated documents.  In
> >>         particular, it contains at least one U-label or A-label, but
> >>         otherwise may contain any mixture of NR-LDH labels, A-labels, or
> >>         U-labels.
> > 
> > This is confusing 
> 
> What specifically do you think is confusing? We tried to get it right, 
> but clearly didn't succeed...

At this rate we'll never be done.  The less said about IDNs the better.
All that needs to be said, is that The DNS-ID in certificates stores all
IDNs in A-label form.  A similar statement should be made for URI-ID and
SRV-ID.  The only context in which U-labels creep into certificates is
as the domain-parts of non-ASCII SmtpUtf8Mailbox names, which are not
covered in this document.

> > I stronly recommend you have similar rules here. Separate potential
> > mapping from comparison of domain names which in turn must be
> > separated from policy for what code points are allowed.

Delete all text that tries to specify/clarify/relax/tighten/... IDN
conformance rules.  This is a tar-baby, that will never let you go.

Just reference IDNA2008 for definitions, and move on.  Applications
that use UTS-46 will pretend they didn't see those definitions, and
the others might actually implement IDNA2008 (by finding a library
that actually uses Unicode property tables to directly implement
IDNA2008 rules, rather than use the UTS-46 IDN API).

> It seems that we should at least say that U-labels need to be
> converted to A-labels first, no? Or do you think that is implied by
> referencing the DNS rules (which don't allow U-labels natively)?

The reference identifiers for IDN names in certificates are in their
A-label forms.  The application developer can draw their own conclusions
as to what to do.  If they don't perform conversion, the names won't
match (at least for certificates issued by public CAs).  And in any case
the ASN.1 data type for DNS-ID is IA5String, which is not particularly
U-label friendly.

> > It *might* also include wording about:
> > 
> > - If a domain name include unicode characters, and case folding
> > equivalent approximate matching is expected by the client, mapping
> > from one unicode character to another must take place before the
> > A-label is created from the U-label. And reference section 4.2 in
> > RFC 5894.
> 
> Thanks for the reminder about that section.

My take is, don't go there.  The certificate holds A-label forms.
Good luck.

> > - If a domain name include code points that are DISALLOWED according
> > to IDNA2008 or any other policy, for example a registry, it MUST be
> > defined in this document whether it SHOULD be allowed to do a
> > comparison of the domain names or not. If a label include 0x00 bytes
> > for example (which is normally never allowed in any protocol) should
> > such a lable be able to get a "match" when the domain name is to be
> > compared?
> 
> It seems like a bad idea to match on DISALLOWED code points! But see below.

My advice: do not specify/clarify/tighten/relax IDN rules.

> I believe we included that text only to note that the wildcard matching 
> for certificates is more constrained that for DNS. Do you think that 
> further clarifications are needed?

Wildcards in DNS are not presented identifiers.  This document talks
about wildcards in presented identifiers.  If that's not clear, make
that clear. The rest follows.

> 
> >>     An IP-ID matches based on an octet-for-octet comparison of the bytes
> >>     of the reference identity with the bytes contained in the iPAddress
> >>     subjectAltName.  Because the iPAddress field does not include the IP
> >>     version, a helpful heuristic for implementors is to distinguish IPv4
> >>     addresses from IPv6 addresses by their length.
> > 
> > Why "octet by octet"?
> 
> Do you suggest some other text? Specifically do you have in mind "bit by 
> bit" perhaps?

Just the entire address verbatim, the point is that there is no partial
prefix, suffix, or other incomplete matching.  This is about *how* to
perform comparisons of binary blobs, but *what* to compare (the entire
reference identifier against the entire presented identifier, which
must match in their length *and* content).

> We were trying to be more precise about what "the same" means, but as we 
> know it can be a challenge to get that right.

Perhaps my text above could be trimmed to something that captures the
idea.

> >>     If the identifier is an SRV-ID, then the application service name
> >>     MUST be matched in a case-insensitive manner, in accordance with
> >>     [DNS-SRV].  Note that the _ character is prepended to the service
> >>     identifier in DNS SRV records and in SRV-IDs (per [SRVNAME]), and
> >>     thus does not need to be included in any comparison.
> > 
> > Please reference one place in this document where case sensitivity is explained. Do not repeat text.

I would really like to see the clause about "does not need to be
included" dropped with prejudice.  What exactly are we optimising here
and why???  Compare the full reference identifier (case-insensitively)
against the full presented identifier, "_" character and all.

> >>     Relevant security considerations for handling of internationalized
> >>     domain names can be found in [IDNA-DEFS], Section 4.4, [UTS-36], and
> >>     [UTS-39].
> 
> Does that text seem correct or appropriate?

Run don't walk away from specifying/clarifying/tightening/relaxing IDN
conformance rules.  Certificate presented identifiers are A-labels.
Good luck.  If all the stars line up right, and the registrars, CAs,
browsers, ... all agree on which strings map to which A-labels, great.
If not, avoing deploying critical services at fragile DNS node names.

If browsers decide to completely punt confusables, the security issues
will eventually bubble up and whatever steps seem appropriate will be
taken.  I'd like to have a browser that uses colours to distinguish
code pages so that Russian letters in URLs are obviously different
from Latin, and the alphabets I can't read (Chinese, Korean, Arabic, ...).
are in A-label form.  I may never get such a browser, but this is I
posit a UI issue, and not a certificate issue.

Of course there are many other ways to get confusion beside look-alikes
from different scripts, but again trying to settle this here will not
IMHO make any progress.

-------

On Tue, Feb 07, 2023 at 11:49:19PM -0500, John C Klensin wrote:

> (You can ignore me when I kick this dead horse but, outside
> Content-type registrations, the odd sentence in the third
> paragraph of Section 2.1 of RFC 5890, and a few other,
> IETF-specific, contexts, there is no such thing as "US-ASCII").

FWIW, "us-ascii" is a MIME charset.

> > It seems that we should at least say that U-labels need to be
> > converted to A-labels first, no? Or do you think that is
> > implied by referencing the DNS rules (which don't allow
> > U-labels natively)?

It doesn't really matter than the DNS wire form is A-labels, this
document specifies the use of A-labels in presented identifiers.
Certificates can be used in networks that are disconnected from the
global DNS and where name resolution works in some other way.  DNS-IDs
use DNS label syntax, but need not actually be names registered in DNS.

Of course, once SVCB/HTTPS records come into play applications that
process those will inevitably have to work with DNS, but that's not a
universal requirement.

-- 
    Viktor.