Re: [Uta] Unofficial I18ndir review of draft-ietf-uta-rfc6125bis

[Viktor Dukhovni <[e-mail]>]

On Tue, Dec 27, 2022 at 03:31:37PM +0300, Valery Smyslov wrote:

> From: John C Klensin [mailto:[e-mail]] 
>
> (2) The document makes several references to URIs, but only RFC
> 3986 appears to be referenced.  In the real world in which
> certificates are established and used and in which differences
> in specifications and practices often provide opportunities for
> exploitation by would-be evildoers, there are at least two,
> probably three, URI specifications (IETF/RFC3896, WHATWG, and
> maybe W3C).  Each is treated as authoritative by some Internet
> actors and they are not consistent with each other.  That
> situation and its implications should be pointed out, at least
> as a Security Consideration.

An application that initiates a connection to some particular URI, and
is prepared for or expects server certificates matching that URI will
have some mechanism to determine URI equality.  I am not sure I see a
problem here.  If the application and server operator sufficiently
disagree on how to represent the URI the certificates may fail to match,
but I don't see much room for false matches.  This could perhaps be an
interoperability, but not a security issue.

> (3) Similarly, there are, in practice, at least two different
> specifications for IDNs.  While the IETF considers it obsolete,
> IDNA2003 is still referenced periodically and might constitute
> another.

We should continue to consider IDNA2003 obsolete.  The applications that
support IDNs appear to have generally moved on.

> Another is specified, with the claim that it is a
> transition strategy but that has shown no signs in recent years
> of being used that way rather than as an alternate spec, by the
> Unicode Consortium as UTS#46 [4].

Indeed UTS#46 has a significant market advantage, because while the IETF
produces "paper" documents, UTS#46 is actually implemented in running
code (libicu).  So, for example, Postfix supports IDNs per UTS#46,
without the legacy IDNA2003 crutches:

    https://www.postfix.org/postconf.5.html#enable_idna2003_compatibility

the aboe controls the value of "midna_domain_transitional" in:

    idna = uidna_openUTS46(midna_domain_transitional ? UIDNA_DEFAULT
                           : UIDNA_NONTRANSITIONAL_TO_ASCII, &error);
    anl = uidna_nameToASCII_UTF8(idna, ...);
    uidna_close(idna);

But this matters little in certificates, because any possible confusion
is at a higher layer.  Typically, the application was able to resolve
the putative UTF8 domain name to an address, so already performed the
U-label to A-label transformation to find the name in DNS.  Whatever
A-label form it came up with, is the name to match in the certificate.
Any IDN issues relevant to TLS certificate verification are at the UI
layer, not the connection security layer.

> (4) Section 6.3 strongly implies that there are two types of
> domain names: the traditional, all-ASCII, variety known as the
> "preferred name syntax"  in RFC 1034 Section 3.5 and IDNs.  But
> it does not say that but, instead, points to RFC 1034 as a
> whole.  RFC 1034 imposes no restrictions on what can be in a the
> octets that make up a label (see, e.g., Section 11 of RFC 2181).
> If you mean that the labels of the domain names you are
> considering must be IDNs, all-ASCII, or "preferred syntax" (the
> last two are different), figure out a way to say that explicitly.

It might be better to say that conversion of U-labels to A-labels is an
application layer problem that happens outside the TLS channel security
boundary.  By the time the application is verifying the certificate it
should have already determined the A-label form of the service FQDN, and
use that name both to locate the network addresses up the TCP connection
and to verify the certificate.  In HTTP for example, the A-label form
is also sent in the "Host:" header.

    $ curl -v -kLI --http1.1 https://шшш.mail.de
    ...
    > HEAD / HTTP/1.1
    > Host: xn--x1aaa.mail.de
    > User-Agent: curl/7.82.0
    > Accept: */*
    ...

The A-label conversion is already done by time the application wants to
complete a verified TLS connection.  Also the name sent in SNI is in
A-label form (and happens before certificate verification).  Even if the
application is not doing HTTP, bottom line, the construction of the
A-label form of the peer name for certificate matching is the
responsibility of the application or the libraries that mediate such
connections, ofr this document it is sufficient to say that the DNS-ID
and URI-ID in certificates use A-label names, and that's what you
need to match.

> (6) Under 6.4, the draft says "The iPAddress field does not
> include the IP version, so IPv4 addresses are distinguish from
> IPv6 addresses only by their length (4 as opposed to 16 bytes)".
> I don't know if that can be fixed or if this document would be
> the appropriate place to fix it, but, as long is there are
> people, companies, governments, or other entities out there with
> bright ideas about IPvN, N > 6, out there, basing operations on
> this field conditional on a heuristic that depends on length
> does not seem like a good idea.  And, btw, the preferred term is
> usually "octets" rather than "bytes".

This is not a problem, if such addresses ever show up, they'd
need to use a new "otherName" type.

> (8)  If all of your processing (not just comparisons) and what
> you allow to store in certificates is based on A-labels, then
> I'm not sure what Section 7.2 means.

A throw-away note.  What a human reader makes during manual inspection
of a certificate is not terribly relevant, and highly dependent on
how user-agents display certificates to users (do they decode
a-labels to u-labels for presentation?).  All of that is outside
the scope of the document which is how software-agents verify
the reference identifier (A-label FQDN) against presented identifiers
(A-label FQDNs).

On Wed, Jan 11, 2023 at 05:25:04PM -0700, Peter Saint-Andre wrote:

> > * In (6) "IPvN, N > 6, out there, basing..." should have been
> > "IPvN, N > 6, out there, making..." or "IPvN, N > 6, out there,
> > defining...".
> 
> ACK.

See above.  This is not a problem.

-- 
    Viktor.