On 12/17/22 6:40 AM, Qin Wu wrote:
Hi, Peter:
-----邮件原件-----
发件人: Peter Saint-Andre [mailto:stpe...@stpeter.im]
发送时间: 2022年12月17日 6:51
收件人: Qin Wu <bill...@huawei.com>; ops-...@ietf.org
抄送: draft-ietf-uta-rfc6125bis....@ietf.org; uta@ietf.org
主题: 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
u...@example.net. ” 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
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
