On Mon, Mar 30, 2015 at 05:21:34PM +0000, Viktor Dukhovni wrote: > On Mon, Mar 30, 2015 at 11:57:27AM -0500, Nico Williams wrote: > > > 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.
Requiring client support for the lookup protocol solves this. Sites with many mailboxes can implement the lookup protocol and not publish mailbox names in the DNS. > * Suffer from bloated caches full of negative replies for billions > of accounts. Ditto. > * 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. ] Ditto. > If none of the above are compelling, then going back to a lossless I think they are quite compelling > 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). > [...] Don't we need DANE for e-mail signature signing key verification too? Nico -- _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
