On 12/19/22 12:33 AM, Qin Wu wrote:
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
[HTTPSbytes] can be solved in the solution proposed in web specific
specification while attack described in [Defeating-SSL] 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?
[Qin Wu] Thanks for history revisiting, Yes, quoting these practical mitigation
that has already defined somewhere perfectly make sense and addresses my
concern, especially section 3.2 of RFC9325, I am happy if you can add these
clarifications and quotations which make me not scared about wildcard
certificates any more.:-)
Thanks you for taking care of my remaining comment.
Great.
I had one more thought regarding [Defeating-SSL]. Notice that the
example on Slide 92 of that presentation is as follows (actually
`google` is supposed to be `gmail` but you get the idea):
www.google.xn--
comaccountsservicelogin-5j9pia.f.ijjk.cn
According to the rules in §6.3 of draft-ietf-uta-rfc6125bis-08, that
domain does not match *.ijjk.cn because only one wildcard character is
allowed and the wildcard must match only the leftmost label. The most
that could be matched would be f.ijjk.cn. Using this label, the fake URL
would be:
https://com╱accounts╱servicelogin.f.ijjk.cn
Could that still fool someone into clicking it? Perhaps, but without the
widely known company or service name in the fake URL perhaps the risk is
lower.
However, I don't know if this really helps, because even though various
full stop characters (e.g., U+3002 IDEOGRAPHIC FULL STOP) are disallowed
by RFC 5892 in internationalized domain name labels, I have no doubt
that a clever attacker could construct a single label that could fool
some users into believing that the domain looks legitimate.
Peter
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
