[dns-operations] summary of recent vulnerabilities in DNS security.

[Paul Vixie]

Haya Shulman wrote:
> You are absolutely right, thanks for pointing this out.

thanks for your kind words, but, we are still not communicating reliably
here. see below.

> DNSSEC is the best solution to these (and other) vulnerabilities and
> efforts should be focused on its (correct) adoption (see challenges
> here: http://eprint.iacr.org/2013/254).
> However, since partial DNSSEC deployment may introduce new
> vulnerabilities, e.g., fragmentation-based attacks, the
> recommendations, that I wrote in an earlier email, can be adopted in
> the short term to prevent attacks till DNSSEC is fully deployed.

by this, do you mean that you have found a fragmentation based attack
that works against DNSSEC?

by this, do you mean that if DNSSEC is widely deployed, your other
recommendations are unnecessary?

in your next message you wrote:

Haya Shulman wrote:
> ..., the conclusion from our results (and mentioned in all our papers
> on DNS security) is to deploy DNSSEC (fully and correctly). We are
> proponents of cryptographic defenses, and I think that DNSSEC is the
> most suitable (proposed and standardised) mechanism to protect DNS
> against cache poisoning. Deployment of new Internet mechanisms is
> always challenging (and the same applies to DNSSEC). Therefore, we
> recommend short term countermeasures (against vulnerabilities that we
> found) and also investigate mechanisms to facilitate deployment of DNSSEC.

in 2008, we undertook the short term (five years now) countermeasure of
source port randomization, in order to give us time to deploy DNSSEC. if
five years made no difference, and if more short term countermeasures
are required, then will another five years be enough? perhaps ten years?
exactly how long is a "short term" expected to be?

for more information, see:

http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/

vixie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20131019/2a7e3d07/attachment.html>