Last Call Review of draft-ietf-uta-rfc6125bis-12
review-ietf-uta-rfc6125bis-12-dnsdir-lc-spacek-2023-05-21-00

Hi,

I was assigned as the dnsdir reviewer for draft-ietf-uta-rfc6125bis-12.

For more information about the DNS Directorate, please see
https://wiki.ietf.org/en/group/dnsdir

The draft seems clear to me, and ready with couple nits.

Some nits below might be just my misunderstanding of PKIX and/or things
intentionally left undefined by the WG. Feel free to ignore these.

>  1.5. Terminology
>
> source domain:
>
>     The fully qualified domain name (FQDN) that a client expects an
application service to present in the certificate. This is typically input by a
human user, configured into a client, or provided by reference such as a URL.
The combination of a source domain and, optionally, an application service type
enables a client to construct one or more reference identifiers. This
specification covers FQDNs only and provides no support for bare hostnames or
any other name that does not include all labels. This paragraph is missing
references for: - FQDN - label - bare hostname

FQDN and label are label defined in [DNS-TERMS].

IMHO it's better to avoid "hostname" it is somewhat ambiguous and evolved over
time (see [DNS-TERMS]).

Closest thing I've found is "partially qualified domain name", also mentioned
in [DNS-TERMS] as part of FQDN definition.

More importantly, the underlying DNS protocol does not provide means to
transmit non-FQDNs (e.g. in SRV RR). SRVName does not mention non-FQDNs at all,
so I assume it assumes (:-) FQDNs as well, albeit IA5String can theoretically
contain non-FQDN.

For that reason I think last sentence could be stronger. I propose something
along those lines:

... This specification covers FQDNs only. Use of any names which are not fully
qualified is explicitly forbidden and can lead to unexpected behavior.

(It should fail close, but why take chances. Or maybe this constraint should be
mentioned in 1.4.2. Out of Scope ?)

>  2. Identifying Application Services
>
> This document assumes that an application service is identified by a DNS
domain name (e.g., example.com), an IP address (IPv4 or IPv6), or by an
identifier that contains additional supplementary information. Supplementary
information is limited to the application service type as expressed in SRV
(e.g., "the IMAP server at example.net") or a URI. Nit: Albeit I understand it
in general terms, I would prefer a clear reference to SRV RR and/or SRVName.

>  3. Designing Application Protocols> A protocol can allow the use of an IP
address in place of a DNS name. This might use the same field without
distinguishing the type of identifier, as for example in the "host" components
of a URI. In this case, applications need to be aware that the textual
representation of an IPv4 address can appear to be a valid DNS name, even
though it is not; the two types can be distinguished by first testing if the
identifier is a valid IPv4 address, as is done by the "first-match-wins"
algorithm in Section 3.2.2 of [URI]. Note also that by policy, Top-Level
Domains ([DNS-TERMS]) do not start with a digit (see Section 2.2.1.3.2 of
[ICANN-AGB]); historically this rule was also intended to apply to all labels
in a domain name (see Section 2.3.1 of [DNS-NAMES]), although that is not
always the case in practice. Mother of all nits: _Technically_ IPv4 address
_is_ a valid DNS name (DNS names are superset of hostnames). There is a policy
saying that we should not use these names for hosts or TLDs, but it's still
technically valid.

In any case, "first-match-wins" algorithm works.

>  6. Verifying Service Identity
>
> At a high level, the client verifies the application service's identity by
performing the following actions: > The client constructs a list of acceptable
reference identifiers based on the source domain and, optionally, the type of
service to which the client is connecting. > The server provides its
identifiers in the form of a PKIX certificate.The client checks each of its
reference identifiers against the presented identifiers for the purpose of
finding a match. When checking a reference identifier against a presented
identifier, the client matches the source domain of the identifiers and,
optionally, their application service type. Probably nit: The word "optionally"
makes me twitch. Maybe

... and, if present on both sides, their application service type.

- or something like that?

>  6.3. Matching the DNS Domain Name Portion
> 1.   There is only one wildcard character.> 2.   The wildcard character
appears only as the complete content of the left-most label.

> If the requirements are not met, the presented identifier is invalid and MUST
be ignored.A wildcard in a presented identifier can only match exactly one
label in a reference identifier. This specification covers only wildcard
characters in presented identifiers, not wildcard characters in reference
identifiers or in DNS domain names more generally. Therefore the use of
wildcard characters as described herein is not to be confused with DNS wildcard
matching, where the "*" label always matches at least one whole label and
sometimes more; see [DNS-CONCEPTS], Section 4.3.3 and [DNS-WILDCARDS].For
information regarding the security characteristics of wildcard certificates,
see Section 7.1. I recommend adding an explicit statement that rules given here
_also_ intentionally deviate from RFC 4592 section 2.1.3.

Reasoning: It explicitly mentions deviation from 4.3.3 but a causal reader
might be confused by preceding 2.1.3.

>  6.4. Matching an IP Address Portion
> This document does not specify how an SRV-ID reference identity can include
an IP address.

I think SRV-ID clearly says it's just DNS name, so the presented identifier
cannot match an IP address. I think this section should clearly say that IP
addresses cannot match SRV-ID.

> 7.4. IP Addresses

Maybe add a reference to section 3. Designing Application Protocols where this
is discussed (in the last paragraph)?

--
Petr Špaček