ietf-asrg
[Top] [All Lists]

[Asrg] RE: DNSSEC has it's own deployment problems (Re: Keith, Hadmut bo th right)

2003-03-06 14:33:34

On Thu, Mar 06, 2003 at 04:50:18AM -0800, Hallam-Baker, Phillip wrote:
The widespread DNS spoofing scenarios proposed are theoretical not
practical. 

Probably you missed the earlier post with a pointer to a paper on DNS
attacks:

No I saw the post. I believe it is plain wrong.

DNS Cache poisoning etc attacks are actually quite hard to do if you 
do not know the address of the resolver asking the question. To take your
assertions by case:

a) the sender knows when the SMTP server will make the DNS request (he
just injected the mail) so he can send a flurry of DNS UDP response
packets to arrive before the real response;

This attack does not work if the SMTP server pushes the DNS request onto 
a caching resolver on a separate IP address.

If however the attack does turn out to be a problem we fix the broken-ness
of DNS. A flooding attack is easily deleted with a unique request ID
cookie, we do not need to even go as far as deploying DNSSEC.

b) the sender can choose the TTL on his forged DNS response, making it
last for weeks;

Sounds like a pretty recognizable signature. It is in any case a simple
matter to limit the TTL that the cache recognizes.

c) during this time he can spam at full volume.

The three cases you specify are actually the same case repeated.


and a description of the way that RMX proposal interacts badly to make
DNS even more vulnerable in the context of RMX.

RMX is a weak authentcation proposal. I believe in public key based
approaches.


However there is no upgrade path to installing DNSSEC as a way to
fixing the problem, because DNSSEC has a version rollback attack.  An
attacker can trick a DNSSEC client into thinking the DNSSEC server is
just a DNS server.  Even worse it's the same pattern of attack that
makes RMX vulnerable to DNS attacks.

No it does not. The NXT record is there to prevent rollback attacks.

The problem with DNS is that there are people who don't want the 
protocol to be deployable in the large zones and have done everything 
they can to stop this from happening.


To fix it you'd have to fully deploy DNSSEC and _disable_ DNS.  This
is likely a problem as hard as fixing spam, as it's of similar order
to replacing SMTP as a protocol with a cut-off date.

Untrue

On top of that DNSSEC presumes a PKI, which as we've seen over the
last 5 years is a hard thing to deploy in and of itself.

Also untrue.


                Phill
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>