Re: [Uta] Opsdir early review of draft-ietf-uta-rfc6125bis-08

[Peter Saint-Andre <[e-mail]>]

Hello and thanks for the early review.

I've provided a few comments inline.

On 12/16/22 4:09 AM, Qin Wu via Datatracker wrote:
> Reviewer: Qin Wu
> Review result: Has Nits
> 
> I have reviewed this document as part of the Operational directorate's ongoing
> effort to review all IETF documents being processed by the IESG. These comments
> were written with the intent of improving the operational aspects of the IETF
> drafts. Comments that are not addressed in last call may be included in AD
> reviews during the IESG review.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> This document specifies procedures for representing and verifying the
> application services identity in TLS interaction with PKI X.509 certificates.
> 
> I believe this document is well written and ready for publication.
> 
> Major issue:
> No
> 
> Minor issues:
> 1.Section 1.2 Applicability
> s/ cetrificate/certificate

Already noted: 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/69

> 2. Delegated domain definition
> “ For example, a server at mail.example.net could be a delegated domain for
> connecting to an IMAP server hosting an email address of [e-mail]. ” I
> can not parse this sentence, is the server a delegated domain? Which domain is
> the source domain? Which domain is delegated domain ? please make this clear in
> the example.

Yes, this could be clearer. In this case the source domain is 
example.net (i.e., the `domain` portion of the `addr-spec` construct 
defined in RFC 5322).

> 3.Section 2 Identifying Application Service What is meaning
> difference between _direct_ and direct or _indirect_ and indirect? In section
> 2, sometimes _direct_/_indirect_ is used, sometimes direct/indirect is used.

There is no semantic difference between the two - apparently in 6125bis 
we added the underscores to indicate a kind of emphasis, but we did not 
follow that convention in RFC 6125.

> 4.Section 2 said:
> “   We can categorize the three identifier types as follows:
> 
>     *  A DNS-ID is direct and unrestricted.
> 
>     *  An IP-ID is direct and unrestricted.
> 
>     *  An SRV-ID is typically indirect but can be direct, and is
>        restricted.
> 
>     *  A URI-ID is direct and restricted.
> ”
> Three identifier types or four identifier types? My impression is the latter.

There are four - we added IP-ID recently and neglected to update that text.

> 5.Section 2
> s/possibile/possible

Noted.

> 6.Section 3 said:
> “In this case, applications need
>     to be aware that the textual representation of an IPv4 address can
>     appear to be a valid DNS name, though it is not.  ”
> it in the text ‘though it is not’ is referred to digit representation of an
> IPv4 address? Or not?

Because Martin Thomson provided that text, perhaps he can clarify his 
intent.

> 7.Section 7.1
> I am surprised there is no protection measures to mitigate risk of vouching for
> rogue or buggy hosts in this document?

It seems to me that methods for mitigating the attacks described in 
[Defeating-SSL] and [HTTPSbytes] are probably out of scope for this 
document.

The [HTTPSbytes] attack depends on cross-site scripting, and thus I 
think that mitigations should be explained in web-specific 
specifications (e.g., JavaScript, HTML input validation, cookies).

The [Defeating-SSL] attack depends on starting with plaintext HTTP (not 
HTTPS) and of course no certificate checking happens over plaintext 
HTTP. The attack also includes further trickery involving UX differences 
between U-labels and A-labels as well as confusable characters, but in 
Section 6.3 we already specify that domains must be checked as A-labels 
and in Section 7.2 we point to relevant specifications regarding 
internationalized domain names. These matters are notoriously thorny and 
difficult to solve, so it's not clear to me how much more we can say. 
Naturally, suggestions are welcome.

Peter