>> 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. Thanks for pressing on this point. Peter _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
