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

From: Adam Back <[email-masked]>
Date: Thu, 6 Mar 2003 20:21:49 +0000

Phill,

> DNS Cache poisoning etc attacks are actually quite hard to do if you 
> do not know the address of the resolver asking the question. 

And this address is protected how?  It is easy to discover, commonly
advertised (think ISPs), and at best weak security by obscurity.

> 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.

The request ID within DNS is 16 bits.  If you propose adding such a
larger cookie to both sender and recipient then you have to deploy
that which is again another problem to solve which adds over all
complexity to problem of deploying a fixed to the SMTP protocol.

> >>b) the sender can choose the TTL on his forged DNS response, making it
> >>last for weeks;
> 
> Sounds like a pretty recognizable signature. 

Incorrect.  There will be a wide variety of TTLs used in the field,
they can legitimately change over time; all the attacker has to do is
choose a plausible looking and long TTL.

> It is in any case a simple matter to limit the TTL that the cache
> recognizes.

Which tends to impacts performance.

> > 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.

This is a political debate for another list.  Hardly "untrue", at the
very least it's a debatable point, stock prices and recent histories
of PKI bankruptcies could be read to indicate PKI has it's own
technical and economic infrastructure deployment problems.

Anyway my point is more to the overall complexity of a scheme.  An
anti-spam scheme that starts with "step 1 deploy global PKI", I think
is undisputably more complex than a system like hashcash which has no
infrastructure requirements.

Adam
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 06 Mar 2003 16:00:04 -0500

> technical and economic infrastructure deployment problems.

Heh.  PKI (at least how it's embodied in current tools etc) is 
tremendously complicated, somewhat non-interoperable amongst vendors 
(though that's finally improving), and it's very difficult to deploy/use 
client PKI in the large-scale even with relatively uniform 
installed-base software on the user-end. We have the bloody fingers to 
prove it.

PKI is coming, but it's not mature enough yet. Security Dynamics, 
Versign's parent (or grandparent or something, I've lost track), has 
advertising videos where some of their other customers are saying the 
same thing.  Dow Chemical IT said in 1999 or 2000 "We'll start getting 
serious about client PKI in 2004". I think they were a trifle too 
optimistic.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 6 Mar 2003 11:43:17 -0800

> 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

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

Also untrue.

		Phill