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

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

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