Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME

[Michael StJohns <[e-mail]>]

At 01:36 AM 10/13/2008, Ben Laurie wrote:
>Edward Lewis wrote:
>>> ps - anyone want to take a whack at documenting how various applications
>>> should handle various DNSSEC outcomes?  The ones I can think of off
>>> the top
>>> of my head that should be done are: SMTP (both submitter to MTA and MTA
>>> to MTA), HTTP (what the browser does *before* the user gets involved -
>>> pretty sure just exposing the DNSSEC resolution state isn't the best
>>> answer), SSH,  peer-to-peer.
>> 
>> DNSSEC was built ("repeat chorus") to stem cache poisoning, i.e.,
>> protect the admission of DNS data to the cache.  It wasn't meant to
>> protect the applications making use of the data.  If an application
>> wants to act like a cache with a verifier, fine.  Then it asks for
>> everything with CD, gets as much raw data, and does it's own check. If
>> it can't reach the source (because of firewalls, forwarders, etc.,),
>> well it's up a creek anyway.
>> 
>> To an application - either their is an answer in DNS or not.  The grey
>> area is too hard to make use of, a general solution isn't useful.  It's
>> like with lame delegation testing in the reverse map. There are a lot of
>> screw ups there, a lot follow certain pathologies that, even common,
>> make up a small percentage of the total problems. It isn't worth trying
>> to diagnose for the few predictable misconfigurations.
>
>Surely the point is that DNSSEC changes the possible answers from:
>
>1. RR exists and here it is.
>2. RR does not exist.
>3. Server not reachable (or otherwise broken).
>
>to
>
>1. RR exists and here it is.
>2. RR does not exist.
>3. RR exists but is broken in some way.
>4. Server not reachable (or otherwise broken).

I don't think its this simple... really.

Basic DNS has the 3 answers in your first group - although I'd categorize the last one as "I can't make any determination about whether or not the answer exists for any of a number of reasons" - what Marc describes as "indeterminate".

DNSSEC  add 4 (actually maybe even 5) security states that are somewhat orthogonal to the DNS states:

1. Unknown - I've got no superior trust anchor so I can't make any definite statement about whether or not the answer is secure.
2.  Secure - I've gotten a chain of signatures covering which allow me to determine the answer is securely valid.
3.  Unsecure - I've gotten a chain of signature plus certain other data which tells me in a secure manner that I have no security information about the final answer.
4.  Bogus - I've gotten all the information I've asked for from the system, but I was unable to prove the security - bad signatures, missing keys, etc.
5.  Insecure transition from secure - I've got valid signatures as far as a CNAME or DNAME, but the CNAME or DNAME point into an area of the tree with Unknown trust.

Those three DNS states matrix (somewhat) with the 5 security states to actually give you 15 distinct intersections - but a number of those substates collapse into each other.  (E.g., secure/exist, secure/non-exist, bogus/exist, bogus/non-exist, any/indeterminate, unsecure/any, unknown/any).  You might also consider that DNSSEC extends the original 3 dns resolution states to 4 by adding a "data determinate/dnssec indeterminate" - but those may collapse mostly into the bogus entries.

I'm not trying to be difficult here - but considering each of these intersections and figuring out what to do for each application seems to be a reasonable approach.

Taking specifically email MTA-MTA interactions.  It seems to me that you'd treat (secure | unsecure | indeterminate)/exist as states where you'd allow the MTA to connect and deliver, that you'd treat bogus/any as a reportable security error condition and not deliver (- but would you retry?), that you'd treat any/indeterminate as a retry error condition (e.g. temporary failure), and that you'd treat secure/non-exist as a permanent mail delivery failure.  What would you do with unknown/non-exist - would you treat as a permanent failure or retry after a long or short interval?

Going back to the DNAME/CNAME stuff - DNSSEC provides a mechanism to indicate to a resolver securely that a chain of trust is being turned off  (is ending securely?) (secure delegation to an unsecure zone).  CNAME and DNAME do not have any way of indicating the expected security state of the zone to which they point.  It seems to me that an application might actually care about this when trying to figure out what to do.  Let's pretend for a moment that DNAME has a way of indicating its target status as one of either - must be secure, or don't care.  If the must be secure bit is set and the target can't be validated (either as secure or as delegated to unsecure), then the answer for the whole chain is bogus.  If the bit isn't set, then security resolution for the target restarts with the target - e.g. if the target is under a trust anchor then it must validate or the chain is bogus.  Obviously, this bit doesn't exist - should it?

And finishing up with MTA-MTA - if I use the current model and have a lookup chain to a DNAME that validates, but that the target of the DNAME isn't under a trust anchor - should I deliver the mail?  If so, why?  If not, why?

What do I do if the MX look up is secure, but the A lookup is unsecure or unknown? Vice versa?

What markings if any should go on an email (header notation) to indicate a forwarding routing was based on data with an "unsecure" or "unknown" trust state?  or if the MX was secure and the A wasn't or vice versa?

Should a downstream receiver do anything special for messages marked as above?  Would this ever be a reasonable filtering criteria?



>The question is: what should applications do for state 3? My answer
>would be to treat it like state 4, I think, but there's room for debate.
>
>Cheers,
>
>Ben.
>
>-- 
>http://www.apache-ssl.org/ben.html           http://www.links.org/
>
>"There is no limit to what a man can do or how far he can go if he
>doesn't mind who gets the credit." - Robert Woodruff



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