On 12/19/22 11:18 AM, Peter Saint-Andre wrote:
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
Actually it's only https://f.ijjk.cn - but my point about not getting
too comfortable still stands because attackers are clever...
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
