On Mon, Mar 30, 2015 at 11:57:27AM -0500, Nico Williams wrote:
> > An alternative is to go back to the original base32 encoding, which
> > is lossless, and thus can allow the remote DNS server (a special-purpose
> > DNS lookup engine serving a zone with per-user information) to
> > decode the local-part and perform whatever fuzzy matching may be
> > appropriate.
> >
> > The lossless encoding can support longer names by breaking them up
> > into multiple labels.
> >
> > This allows static DNS to be published where desired, and custom
> > code to produce dynamic results when appropriate.
>
> I like this. A lookup protocol would be optional. But I think we
> need to specify the lookup protocol, and MUAs [that support DANE for
> PGP/S/MIME] will need to support it. The lookup protocol can only be
> optional to provide; it can't be optional on the client-side.
My main concern with this direction is that ISP iterative resolvers
act as open proxies for this protocol, and:
* Add latency because caching of lookup results is unlikely to scale.
* Suffer from bloated caches full of negative replies for billions
of accounts.
* Make it more difficult for the final servers to detect abusive
clients that are doing dictionary (directory harvesting) attacks.
[ Yes email addresses are not secrets, but some opacity can be
useful. ]
If none of the above are compelling, then going back to a lossless
encoding may be a reasonable compromise. Otherwise, we can take
the view that:
* The multitude of addresses per user problem is not a problem,
only a small specific number of addresses will support encryption
(those may need to appear in the public key "certificates" anyway).
* DNS is here and scales to high query volumes.
Or that:
* It must be possible to E2E protect all the variant addresses,
by returning the same keys for variants as for the canonical
address.
* Email operators will not want to publish user to key mappings
in their current DNS, and no DNS front-end to their LDAP or
similar directories is presently available. Since new code
is needed regardless, its protocol may as well be designed
specifically for this problem.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
