On Sat, 14 Jun 2015, John Levine wrote:
I agree with all of that. If it is to be DNS, then hashing works
no worse than most other encodings.
As I'm fairly sure I described in detail before, base32 provides the
option of reversing the encoding at the server, looking up the local
part using whatever fuzzy matching the server wants to use, and
sending an appropriate response.
This pretends that the server can read the human mind of the sender.
It's an equally insecure fuzzy matching logic, but now done at the
server side instead of the client side. How is [email protected] going
to get matched by this server side? To me? to Paul Hoffman? To no one?
If the human starts making up email addresses, it could go wrong. The
client implementation can have a local policy to protect the user. For
example, enigmail shows a big red THIS MESSAGE WILL NOT BE ENCRYPTED
warning.
There's be no need to do any of the
ill-advised local part guessing that people seem to think is required.
You started the guessing part at the client's human. Whether you
outsource their lack of brain power to the email client or the email
server does not matter much - both are insecure and prone to continue
with its human error.
You'd need a stunt server, but if you're publishing 100,000,000 keys,
you're not going to use BIND.
Why don't we let those people speak for themselves if they want to?
It seems those with 100M accounts tend to know something about scaling,
and some of them even wrote a complete DNSSEC server implementation
backed by their own global database store.
If you think that couldn't work, could you explain why not?
Using a red wax sealed envelope couriered by knight could also work.
It is just that this document of the dane working group is proposing
a solution that uses only DNSSEC, with the intension of not needing
to rely on other out-of-band protocols that can be firewalled, DDOSed
and in general do not have the resilience of a distributed DNS backend.
For example, the weeks long attack against pgp.mit.edu would be
something your solution would be equally vulnerable to.
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
