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

[Qin Wu <[e-mail]>]

Hi, Peter:
-----邮件原件-----
发件人: Peter Saint-Andre [mailto:[e-mail]] 
发送时间: 2022年12月17日 6:51
收件人: Qin Wu <[e-mail]>; [e-mail]
抄送: [e-mail]; [e-mail]
主题: Re: Opsdir early review of draft-ietf-uta-rfc6125bis-08

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
[Qin Wu] :Good.
> 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).

[Qin Wu] Thanks for clarification and taking my suggestion. It adds clarity now.
> 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.

[Qin Wu]Okay,  I leave this minor issues to your authors for jurisdiction, I have no strong opinion on this.
> 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.

[Qin Wu] Good.
> 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.
[Qin Wu] Okay, I also forget to note that in the following sentences, it said:
"
Note also that by policy, Top-Level Domains ([DNS-TERMS])
   do not start with a digit (TODO: citation needed).
"
I believe "(TODO: citation needed)" needs to be cleaned up with citation added.
> 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.

[Qin Wu] Thanks for clarification, it looks to me that attack described in [Defeating-SSL] can be solved in the solution proposed in web specific specification while attack described in [HTTPSbytes] can not be solved or fully solved.
If that is the case, why we should quote [Defeating-SSL]? Is [Defeating-SSL] really relevant to this document? Do you assume plaintext HTTP can work with TLS? No?

Peter