[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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



> 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



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