Reviewer: Petr Špaček Review result: Ready with Nits 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
