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

[Michael StJohns <[e-mail]>]

At 08:15 AM 10/13/2008, Ben Laurie wrote:
>Michael StJohns wrote:
>>> 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.
>
>I don't quite see the point of state 5 - why treat that differently from
>1? (Oh, I do now, having read below more carefully)
>
>But you do have a point.

Yup.  More on this in my response to Ed's note which follows.


>> 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.
>
>We should actually figure out what all the distinct states are, rather
>than handwave.

That's really all I'm saying.  If we want DNSSEC to be useful at the application level we need to do something like this.


>> 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?
>
>As with many security decisions, this would depend on requirements. I
>can imagine running an MTA in an environment that only wants to trust
>DNSSEC (or in a mythical future where everything is IPv6, sorry, I mean
>DNSSEC), and so configuring this to "retry but eventually fail" in the
>usual way.
>
>For most people transitioning to DNSSEC, then I'd treat this as a
>permanent failure.

Right.  That's probably a reasonable approach... now to get it standardized... :-) 


>> 
>> 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?
>
>Interesting question. Perhaps it should.
>
>> 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?
>
>Routing headers aren't very rigidly defined now, so this seems orthogonal.

Each hop in email routing adds a Received-From line.  Would it make sense to tag that line in some manner or to add a different element related to DNSSEC?  Not saying that we should or not - but that the discussion is part of DNSSEC plus MTA-MTA handling standardization.

Mike



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