On Wed, Mar 25, 2015 at 04:30:36PM -0400, Paul Wouters wrote:
> On Wed, 25 Mar 2015, Viktor Dukhovni wrote:
>
> >It makes NO difference what protocol is used to find the address
> >-> key mapping. Using something other than DNS just makes it easier
> >to rate control clients, because they are not proxied by their
> >ISP's DNS cache.
>
> You mean it makes it easier to DDOS with a botnet. Either it will
> be some UDP protocol with no state, vulnerable to spoofing, or
> it will be some TCP protocol with state, vulnerable to resource
> starvation.
We've designed the protocol yet. The server can be UDP/stateless,
and yet not be subject to spoofing, and can vend client cookies
(for example) to protect against origin spoofing. The issues you
raise are important when considering the choice/design of the protocol.
> Attacks will just take out the oracle to induce plaintext, or will
> spoof causing a lockout of real clients inducing those end up using
> plaintext.
Taking out the oracle will not induce plaintext any more than
performing the same attack on the authoritative DNS server for the
domain. User keys would have very short TTLs (positive and negative,
to address cache explosion), so a large fraction of queries will
go end-to-end from the MUA to the authoritative server.
> >Actually, for the spammer, the DNS is a more attractive oracle,
> >because queries are cheaper and proxied by ISP caches.
>
> Recursors and Authoritative servers supporting OPENPGPKEY or SMIME could
> rate limit the sending of NSEC3 chains if there are too [many] requests for
> non-existing records - causing them to need to go back to the current
> RCPT TO practise.
Will the recursive servers do that? In practice they'll not have
any code to support these RR types specifically, the new RR types
will just be handled by the generic RR code.
Any harvesting defense is I think more likely to be deployed
effectively at the target server, rather than by thousands of
proxies operated by 3rd parties.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
