Bob - Thanks for pointing out the interesting attack scenario. Fortunately, in my DKA proposal this attack scenario is not possible because an attacker cannot register a key for an email ID without proving mailbox control. So, unless an attacker can register and prove ownership of [email protected], the attacker cannot register a public key for that email ID. So, if the underlying email system domain.tld does not support distinct email IDs [email protected] and [email protected], an attacker cannot use this typo-based attack. If domain.tld does support [email protected] and [email protected] as distinct IDs, then the DKA will and should register them as distinct public keys. While the social engineering attack you suggest is then possible, it is not a DKA-related problem, it is because the domain.tld allows—using your words—dense namespaces that are open to social engineering attacks.
Paul - I agree that it is folly to guess email addresses. I believe the issue that Bob points out is different from the one I suspect you are imagining. Bob’s attack is not looking for a misspelling for a popular email ID like Alice and trying to register its variations. Instead if an attacker wants to attack a specific ID, say [email protected], the attacker can register [email protected], and a public key for it, then social engineering attacks are possible, Thanks both for your time and interest, Cheers Kishore From: Paul Kyzivat <[email protected]> Date: Sunday, June 7, 2026 at 7:44 PM To: Bob Traverz <[email protected]>, [email protected] <[email protected]>, John C Klensin <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: [art] Re: [DNSOP] DNS-designated Public Key Authorities (DKA) Bob, It is folly to try to guess an email address. You will usually fail one way or another, because there is so much competition for "good" names. That's true even if the name is as unusual as mine. (I couldn't get [email protected] - it was already taken.) For that reason providers assign names with disambiguating additions (such as Alice86 and Bob47.) IMO, an email provider ideally SHOULD NOT assign very similar looking user names (e.g., "alice86" and "Alice86") to different, unaffiliated entities. That would prevent the attack you describe. That is different from having a single normalized format for all. Thanks, Paul From: Bob Traverz <[email protected]> Date: Sunday, June 7, 2026 at 6:52 PM To: [email protected] <[email protected]>, John C Klensin <[email protected]>, Paul Kyzivat <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: [art] Re: [DNSOP] DNS-designated Public Key Authorities (DKA) There seems to be a lot of email-related expertise and passion here. I just wanted to point out that John Levine's advice to treat the local part of an email as opaque is not without hazards. The obvious one is that a lot of lookups will fail because people look-up their reasonable expectation of an email id, like "[email protected]<mailto:[email protected]>" or "[email protected]<mailto:[email protected]>". If you don't normalize, the client has to know the exact case, even if the underlying email server normalizes or uses collision avoidance heuristics during registration (one email server I worked with treated upper and lower cases differently but would not allow the registration of an upper-case local part if the lower-case local part was already registered). There is a less obvious effect of not normalizing: social engineering attacks. An attacker wanting to attack [email protected] registers a key for [email protected] as a decoy. Some number of users will query for [email protected] when they intend [email protected], get the wrong key and use it for encryption or signature verification. Since the attacker has the private key for [email protected], the attacker can impersonate [email protected] using the key for [email protected]. This is not a cryptographic attack, but its effect on alice is the same. I don't have a different suggestion from John Levine, but I wanted to point out that normalization leads to sparser namespaces with less chances of accidental collisions. Dense namespaces are more open to social engineering attacks, especially when the namespace contains familiar items like names and domains. Good luck. Bob Traverz On Sat, May 30, 2026 at 1:33 PM John Levine <[email protected]> wrote: It appears that Bob Traverz <[email protected]<mailto:[email protected]>> said: > - Normalization Rules: Before banning dot-removal or plus-tag stripping, >I recommend checking the current practices of Gmail and Outlook. This will >ensure your specification caters to the majority of email IDs. Hi, mail person here. Our RFCs are quite clear that the local part of an address is completely opaque. Any assumptions you make about normalizing local parts are wrong, both in theory and in practice. This is a very hard problem, many people have tried to solve it in the past, and they've all failed. Gmail ignores dots so [email protected]<mailto:[email protected]> and [email protected]<mailto:[email protected]> are equivalent, but I do not know any other system that does that. Sometimes [email protected]<mailto:[email protected]> and [email protected]<mailto:[email protected]> are the same, usually they are not. Sometimes a system manually adds dotted and dotted variants to their alias tables, so it's only as consistent as the maintainer makes it. Some systems allow plus tags, some don't. Some use other characters than plus. It's not even consistent on a single system -- on mine, some foo-bar addresses go to the same places as foo, some don't. Since we added EAI addresses which allow UTF-8 characters in addresses, you can't even do case folding reliably since it's language specific. As a famous example lower case i and upper case I are equivalent in most European languages, but not in Turkish where dotted and undotted i are different characters with upper and lower case versions of both. There are lots of other variations like ö which in German is considered a short version of oe but in Scandinavian languages is not. People have tried to come up with rule sets about mail systems' normalizations. It doesn't work for two reasons. One is that in most cases you don't know what a system's rules really are (what does Gmail do with two dots in a row?), the other is that there are more mail systems than you know, and you'll never have a complete set. The usual approach is to pretend none of this matters and to invent a scheme that will fail randomly on addresses that don't make the same assumptions you do. In this case you can do better, since you can pass the unmodified local part to the keyserver and it can do whatever the local policy is to the address and return the actual key. R's, John
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
