Subject: DNSSEC - Signature Only vs the MX/A issue.

From: Mike StJohns <[email-masked]>
Date: Sun, 26 Nov 2006 22:26:55 -0500

Rob Austein brought up one of the few issues that I hadn't previously 
considered.

His question - In the signature only model, what happens if an 
attacker does a deletion attack on the MX record at a label forcing 
the MTA to fall back to looking up the "A" record?

In PNE, this isn't an issue as you can determine whether or not the 
MX record actually existed.

There's a couple of things that should be said here.  The MX/A 
fallback was simply a hack to deal with the early days of the 
internet and the transition from host table to DNS.  Most email 
accounts were tied to machines on which people had accounts.  The PC 
as an internet node was still quite a few years away.  The host table 
model (prior to DNS) basically mapped [email-masked] to email 
on umd5.umd.edu and used the IP address in the host table as the 
delivery address.  Most MTAs at that point had no concept of MX 
records nor did the admins of the various subnets.  When DNS came 
out, most MTAs still queried only for A records, but eventually 
started querying for MX records.  At this point in time, I'd be 
surprised if there are more than a very few MTAs that don't lead with 
MX queries.  Anyone have data on any MTAs that don't lead with MX records.

Of course, there may also be zones (or names within zones) that host 
MTAs, but that don't also have MX records - anyone have data on this?

I chatted briefly with John Klensin about deprecating this MX/A 
alternate in the next revision to RFC2821 - comments on whether this 
is a reasonable approach?

Going forward, if an MTA is adapted to use SO, it may be a reasonable 
policy to require MX records for a "validated" result.  If an MX 
record doesn't exist, or if its unsigned, then the output of the 
validator would be "unvalidated"  regardless of any validation on the 
"A" alternate and the MTA would take whatever action is appropriate 
for any unvalidated response. The guidance to use MX records would 
added to the general guidance for anyone managing an SO zone.

Any other ideas in this general topic?

Mike

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 28 Nov 2006 12:29:26 +1100

> the MTA to fall back to looking up the "A" record?

	MX/A/AAAA deletion attack will result in mail bounce that
	would otherwise be queued under PNE.

	MTA's treat lookup failure differently to non-existance
	results. Under SO you will have a lot of mail bounce which
	otherwise wouldn't under PNE.  If you are clever enough you
	can also make the bounce, bounce, leading to silent loss
	of the original email.
 
> MX queries.  Anyone have data on any MTAs that don't lead with MX records.

	There are lots of MX only mail domains.  I long ago (+10 years)
	stopped worrying about MTAs that don't lookup MX records.
 
> MTAs, but that don't also have MX records - anyone have data on this?

	There are still lots of those.
 
> is a reasonable approach?

	It would have been if we had said at the start that fallback
	was only a N year transition mechanism.  These days the
	education process would be too hard I think.
 
> added to the general guidance for anyone managing an SO zone.

	There will be more than MX records.  SRV for lots of services
	does / will require PNE.

	Anything that is attempting to deliver a robust automated
	service needs PNE.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 28 Nov 2006 14:58:06 +0100

On Sun, Nov 26, 2006 at 10:26:55PM -0500,
 Mike StJohns <[email-masked]> wrote 

> is a reasonable approach?

Unfortunately, there are other records that are vulnerable to this
attack (SRV, NAPTR), not just MX.

---

From: Mike StJohns <[email-masked]>
Date: Tue, 28 Nov 2006 15:10:47 -0500

At 08:29 PM 11/27/2006, Mark Andrews wrote:

>         results.

It's true that's the policy for existing MTAs (which are non-DNSSEC aware).

>Under SO you will have a lot of mail bounce which
>         otherwise wouldn't under PNE.

Not exactly - if you didn't actually consider the problem and 
mechanism for mitigating them you might be correct, but that's what 
this thread is about.  In any event, I think you'll agree that an SO 
zone is no worse than an unsigned zone.

>   If you are clever enough you

Looking solely at signed zones, if the strong suggestion were that a 
label not have both MX and A records - this could be implemented as 
the zones were signed.  A DNSSEC-capable MTA would still look for 
both records, but would never consider the A records as validated if 
they were the only ones retrieved from the label - somewhere between 
fully secure and bogus in the way it would be treated.

Regardless of PNE or SO, we need to think about how an MTA would 
actually use the DNSSEC data, and that really hasn't happened much yet.

>         There will be more than MX records.  SRV for lots of services

Maybe.  MX/A are alternates for each other - both are considered 
valid for delivery so the deletion of the MX can still result in a 
valid A if the A is signed.  SRV records are linear - if any part of 
the lookup chain (SRV then A) fails validation, then that chain is 
invalid.  Deletion of the first part of the chain (e.g. the SRV 
records) results in failure not an alternate answer.

Again, this goes under the general discussion of what the policy for 
DNSSEC aware applications should be.  (And somewhat about how to 
handle wildcards)

>         Anything that is attempting to deliver a robust automated

This feels to be an assertion rather than a statement of fact.  I'd 
appreciate an expansion of your reasoning here.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 28 Nov 2006 21:47:58 +0100

On Tue, Nov 28, 2006 at 03:13:50PM -0500,
 Mike StJohns <[email-masked]> wrote 
 a message of 25 lines which said:

> Not exactly.  See my previous note to Mark.  SO still protects the
> atomicity of an RRSet - you can delete ALL of the SRV records or
> none of them.  If you delete all of them at a label, the lookup
> fails and you can't proceed.

See Peter Koch's reply :-) Many protocols define a fallback outside of
the RRset. For instance, in
http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-andrews-http-srv-01.txt,
there is a fallback from SRV to A.

---

From: Mike StJohns <[email-masked]>
Date: Tue, 28 Nov 2006 15:13:50 -0500

Not exactly.  See my previous note to Mark.  SO still protects the 
atomicity of an RRSet - you can delete ALL of the SRV records or none 
of them.  If you delete all of them at a label, the lookup fails and 
you can't proceed.  If you do retrieve the SRV records and then 
lookup the referenced A records, the worse that can happen is that 
one or more of the individual A records is deleted and an attacker 
can steer you to one specific system (from the list of validated names).

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Nov 2006 09:56:05 +1100

> fully secure and bogus in the way it would be treated.

	Crazy idea.
 
> Maybe.  MX/A are alternates for each other - both are considered 

	No, they are not alternates.  It is A iff there is no MX.

	There are plenty of domains where the MX goes to in house
	machine and the A goes to a web servers which is hosted by
	a third party.

	If you spoof away the existance of the MX then the email
	gets delivered to the web hosting box which can be legitimately
	running a MTA for its own use.

	PNE provides protection against this sort of misdirection.

> appreciate an expansion of your reasoning here.

	Without PNE you just have to blindly trust that a negative
	answer is correct.  With PNE you have a an assurance that a 
	negative answer is correct and you can take different steps
	to recover when under attack (e.g. log an error and store for
	retry).

---

From: Josh Littlefield <[email-masked]>
Date: Tue, 28 Nov 2006 16:42:49 -0500

> there is a fallback from SRV to A.

Similarly, RFC 3263 defines fallback from NAPTR to SRV (at a different
but related name), followed by fallback to A and AAAA.

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: 978-936-2226       Boxborough, MA  01719-2205

---

From: Mike StJohns <[email-masked]>
Date: Thu, 30 Nov 2006 12:48:58 -0500

>there is a fallback from SRV to A.

Couldn't find a copy - the link you provided is bad.

But that brings up a question.  Just what atomicity guarantees do you 
expect DNSSEC to provide for DNS lookups?

For example - an SRV  or NAPTR record at one name can point to a 
record at another name - do you expect that the entire group of 
related records MUST be signed?  If so how do you enforce it, 
especially if the references point outside the zone?

If you're talking about A record fall back (e.g. asking for a 
SRV/NAPTR/pick one record at www.example.com and falling back to the 
A records at www.example.com), what atomicity guarantee do you need 
in the temporal dimension?  E.g. if I try and retrieve the SRV record 
and am told it doesn't exist - securely - but the zone operator is in 
the process of installing it and does so before I can retrieve 
(perhaps manually) the A record - is that OK even though by the time 
I retrieved the A record the SRV record actually did exist?  Or worse 
yet, the operator was in the process of deleting the A record and 
adding the SRV record - I was able to prove when I went to get the 
SRV record it didn't exist - when I went to get the A record it also 
didn't exist.  Both things were true when I asked, but the result is 
that for some period of time I will believe that no service exists.

PNE makes the entire zone atomic for some measure of atomicity - what 
statement would you make to an application developer about reliance 
on that atomicity?

---

From: Mike StJohns <[email-masked]>
Date: Thu, 30 Nov 2006 13:57:52 -0500

>but related name), followed by fallback to A and AAAA.

*sigh* Yes.

---

From: Mike StJohns <[email-masked]>
Date: Thu, 30 Nov 2006 14:24:08 -0500

> > fully secure and bogus in the way it would be treated.

Let me put it another way.  A zone with only MX records at a label is 
not subject to this deletion attack.  Going forward, SO zones would 
not have A records at a label that also has MX records.

>         No, they are not alternates.  It is A iff there is no MX.

You're correct.  I went back and re-read the relevant section of 2821.

On an aside - I think 2821 is wrong.  The original  "A"  mail deliver 
hack was designed to deal not with the people implementing the zones, 
but with those with old MTAs that were converting over from host 
tables and were only using the A record.  So 2821 doesn't actually 
work for that case - zones aren't required to have MTAs at the A 
record.  The MX/A hack really needs to be  deprecated.

>         PNE provides protection against this sort of misdirection.

Speaking of hacks...

>         to recover when under attack (e.g. log an error and store for

If I can attack the positive answers, I can attack the negative 
answers.  If you get a negative, unvalidated answer you do 
what?  (e.g. MX records doesn't exist - unvalidated - do you try for 
the A record, try the MX record again or just fail? The end result - 
the mail doesn't get through.)

---

From: Mark Andrews <[email-masked]>
Date: Fri, 01 Dec 2006 09:31:42 +1100

> not have A records at a label that also has MX records.

	You would then have disjoint sets of mail domains and
	hostname rather than the current state of mail domains being
	a super set of working (have address records) hostnames.

	While I see what you are trying to achieve you are throwing
	the baby out with the bath water.  I repeat it is a crazy
	idea.
 
> the mail doesn't get through.)
 
	Think of the various attack modes.  Not all attack modes are
	100% reliable.  With SO you when you get a negative answer
	you *have* to trust it.  With PNE you can just drop the bogus
	negative answers and try again.  Unless the attacker can see
	and intercept all your traffic the valid answer will eventually
	get through.

	With SO you won't be directed to the wrong site, but you can
	still be prevented from getting to the site as the result of
	a forged DNS response.  You can be forced to take a alternate
	strategy that you would not normally take.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 01 Dec 2006 09:56:25 +1100

> especially if the references point outside the zone?

	I expect each in turn to be signed or provably insecure.
	[Anyname not under a trust anchor is provably insecure from
	the resolvers perspective.]
 
> that for some period of time I will believe that no service exists.

	This not a DNSSEC problem.  This is a plain DNS problem.  DNSSEC
	does not change the problem.