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

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

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
>