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

[Qin Wu <[e-mail]>]

Hi, Peter:
I think the root cause of this wildcard certificate issue you described below is 
Wildcard only covers one level of subdomains, instead of multiple level of subdomains,
If we can introduce long prefix match like mechanism to deal with multiple level of subdomain matching, this issue will be easily solved.

The benefit of using wildcard certificate is to use a single certificate for multiple subdomain and one main domain, 
But the cost is to introduce some rat hole for a clever attacker who can take advantage of single level subdomain matching.

-Qin
-----邮件原件-----
发件人: Peter Saint-Andre [mailto:[e-mail]] 
发送时间: 2022年12月20日 2:26
收件人: Qin Wu <[e-mail]>; [e-mail]
抄送: [e-mail]; [e-mail]
主题: Re: Opsdir early review of draft-ietf-uta-rfc6125bis-08

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
>