http://datatracker.ietf.org/doc/draft-levine-dns-mailbox/
The All Names Valid approach has a problem: we're looking for S/MIME or
OPENPGP public keys, so that's what needs to be found. For any public
key algorithms where not every possible bit string is a possible public
key, and where clients can figure that out, the server would have to
generate distinct plausible public keys, otherwise clients could still
enumerate the set of plausible mailboxes.
That would require 2^512 lookups, which I hope we agree is too slow.
Every possible name returns an answer, the vast majority of which have a
null key. Since there's no NXDOMAINs, there's no pointers to tell you
where the next non-null key is. If you're worried about people guessing
addresses through dictionary attacks, they do that now, there's no way to
prevent that without also preventing legitimate lookups, although you can
greatly mitigate the damage by rate limiting when you see a lot of
failures.
I would still prefer to require MUAs to implement the DNS
(base32-encoded) LHS lookup and the pointer-to-HTTPS-server lookup.
Whether mail domains choose to implement static or dynamic DNS lookups,
or the pointer-to-HTTPS-server, should be up to them.
I don't feel strongly about whether base32 or pointer-to-https is better,
but history tells us that if you have two services that are supposed to be
the same, they never are. That's why we need to do experiments to see
what's workable in practice so we can pick one that we know servers can
implmenent and users can use.
That said, I really don't mind living with users having to type in
peers' e-mail addresses correctly.
I just don't see that agreeing with reality. Particularly with non-ASCII
names, there's way too many ways to type what looks like the same thing.
Regards,
John Levine, [email protected], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane