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

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

On 12/17/22 6:40 AM, Qin Wu wrote:
> 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.

Great. We will improve that text in the next version:

https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/72

>> 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.

I'll discuss it with my co-author, but I lean toward removing the 
underscores.

>> 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.

Noted: https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/73

>> 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.

Good catch - we will track down the appropriate citation.

>> 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?

Perhaps some history would be helpful.

When Jeff Hodges and I were working on the document that was eventually 
published as RFC 6125 (this was around 2009 or 2010, before the UTA WG 
was formed), we had a strong desire to remove wildcard certificates 
entirely. However, enough people said "wildcard certificates are 
important" that we were persuaded to leave them in.

Here we are in 2022 and still enough people in the UTA WG said "wildcard 
certificates are important" that we could not gain consensus to remove them.

However, it's also important to note that wildcard certificates can lead 
to various attacks. Although I think it's not the job of *this* 
specification to mitigate those attacks, people should be aware of them.

With that said, we could also make people aware of some of the practical 
mitigations, such as:

1. Don't use wildcard certificates unless absolutely necessary.

2. To help mitigate against the attack described in [Defeating-SSL] 
(which starts with plaintext HTTP), application clients and servers 
could require the use of TLS. Here we could cite §3.2 of RFC 9325.

3. To help mitigate against the attack described in [HTTPSbytes], web 
clients and servers could put in place protections against cross-site 
scripting attacks. Here we could point to the OWASP guidelines at 
https://owasp.org/www-community/attacks/xss/

Do you think that adding some text along these lines would be an 
improvement?

Thanks for pressing on this point.

Peter