Actually, wait, hold on. > I got into this asking similar questions. The fact that more than one Unicode string can produce the same visual output is the biggest security concern in my view. Is that actually resolved? That means that you want the human person at the CA to be looking at the A-label, not the U-label, right? But your draft says: “ Implementations that have a user interface SHOULD convert IDNs to Unicode for display. Specifically, conforming implementations convert A-labels to U-labels for display purposes. “ --- Mike Ounsworth From: secdir <secdir-bounces@xxxxxxxx> On Behalf Of Mike Ounsworth Right, we’re on the same wavelength. I agree that resolving the visual ambiguity problems is important. Good job there. I’m hung up on a specific question that I don’t think is addressed by Security Considerations of IDNA2008 [RFC5890], but surely must be addressed by some DNS spec. My question / concern is this: let’s say that "www.xn--1ca.com" is already registered, has a DNS record, has certificates issued, etc. Then I come along and register "www.á.com", knowing that it is going to have an A-label collision, and then I can get certs for "www.xn--1ca.com" which I actually don’t own. If that’s a problem, then it’ll already be a problem today (ie your draft is not introducing it. So why is that not already a problem? Is it that "www.á.com" ACTUALLY IS "www.xn--1ca.com", so I won’t be able to register it because it’s already taken? --- Mike Ounsworth From: Russ Housley <housley@xxxxxxxxxxxx> > On Jan 2, 2024, at 5: 23 PM, Mike Ounsworth via Datatracker <noreply@ ietf. org> wrote: > > Reviewer: Mike Ounsworth > Review result: Ready > > I have reviewed this document as part of the security directorate's > > On Jan 2, 2024, at 5:23 PM, Mike Ounsworth via Datatracker <noreply@xxxxxxxx> wrote:> > Reviewer: Mike Ounsworth> Review result: Ready> > I have reviewed this document as part of the security directorate's> ongoing effort to review all IETF documents being processed by the> IESG. These comments were written primarily for the benefit of the> security area directors. Document editors and WG chairs should treat> these comments just like any other last call comments.> > The summary of the review is that this document is ready.> > This is my first time contemplating internationalized domain names, so this is> probably more of a historical question: "https://urldefense.com/v3/__http://www.**A.com__;w6E!!FJ-Y8qCqXTj2!b1U_UDfu86CBnhJwcbR7Ycr3yslXJselq8A-88zetnDbryoIEJ4XPArylZqF397qvw4iNOELkSZL8Xj-kal4rw$" converts to the A-label> "https://urldefense.com/v3/__http://www.**A.com__;w6E!!FJ-Y8qCqXTj2!b1U_UDfu86CBnhJwcbR7Ycr3yslXJselq8A-88zetnDbryoIEJ4XPArylZqF397qvw4iNOELkSZL8Xj-kal4rw$". Is "https://urldefense.com/v3/__http://www.**A.com__;w6E!!FJ-Y8qCqXTj2!b1U_UDfu86CBnhJwcbR7Ycr3yslXJselq8A-88zetnDbryoIEJ4XPArylZqF397qvw4iNOELkSZL8Xj-kal4rw$" itself a valid domain name, and does> that introduce ambiguity that could lead to security issues? I assume that this> ambiguity is already sufficiently addressed in one of the referenced specs, but> maybe bears repeating in this document's Security Considerations.Mike:I got into this asking similar questions. The fact that more than one Unicode string can produce the same visual output is the biggest security concern in my view. The strings would fail an exact match, but they look the same to the human. This is covered in RFC 5890.By always using A-labels in certificates, we are avoiding one source of this type of confusion. Allowing either "https://urldefense.com/v3/__http://www.**A.com__;w6E!!FJ-Y8qCqXTj2!b1U_UDfu86CBnhJwcbR7Ycr3yslXJselq8A-88zetnDbryoIEJ4XPArylZqF397qvw4iNOELkSZL8Xj-kal4rw$" or "https://urldefense.com/v3/__http://www.**A.com__;w6E!!FJ-Y8qCqXTj2!b1U_UDfu86CBnhJwcbR7Ycr3yslXJselq8A-88zetnDbryoIEJ4XPArylZqF397qvw4iNOELkSZL8Xj-kal4rw$" required libraries to perform conversion before processing name constraints. Removing that conversion eliminates one source of security problems.I would be glad to add a paragraph to the security considerations: The Security Consideration related to IDNA2008 in Section 4 of [RFC5890] are relevant to this specification.Russ |
<<attachment: smime.p7s>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
