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

[Mark Andrews <Mark_Andrews@isc.org>]

> At 08:29 PM 11/27/2006, Mark Andrews wrote:
> 
> > > 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?
> >
> >         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.
> 
> 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
> >         can also make the bounce, bounce, leading to silent loss
> >         of the original email.
> >
> > > In PNE, this isn't an issue as you can determine whether or not the
> > > MX record actually existed.
> > >
> > > > 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
> .
> >
> >         There are lots of MX only mail domains.  I long ago (+10 years)
> >         stopped worrying about MTAs that don't lookup 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?
> >
> >         There are still lots of those.
> >
> > > 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?
> >
> >         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.
> 
> 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.

	Crazy idea.
 
> 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.
> 
> >
> > > 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.
> >
> >         There will be more than MX records.  SRV for lots of services
> >         does / will require PNE.
> 
> 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.

> 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
> >         service needs PNE.
> 
> This feels to be an assertion rather than a statement of fact.  I'd 
> 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).
 
> > > Any other ideas in this general topic?
> > >
> > > Mike
> > >
> > >
> > >
> > >
> > > --
> > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> > > the word 'unsubscribe' in a single line as the message text body.
> > > archive: <http://ops.ietf.org/lists/namedroppers/>
> >--
> >Mark Andrews, ISC
> >1 Seymour St., Dundas Valley, NSW 2117, Australia
> >PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org

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