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

From: Edward Lewis <[email-masked]>
Date: Mon, 6 Oct 2008 10:55:02 -0400

At 18:04 -0400 9/24/08, Michael StJohns wrote:
>If "intermediate validation to protect legacy stub resolvers" were deprecated,
>I'd agree with you.  (can we please huh huh can we deprecate it????)

If we deprecate that, what's the point of DNSSEC?  DNSSEC is designed 
to stem cache poisoning, so that caches don't give out answers they 
can't verify to their clients.  The client to cache is protected by 
TSIG, TKEY, IPSEC, or maybe just crossing one's fingers and hoping 
for the link to be secure.  (Legacy has to count on the latter - 
assuming legacy is pre-TSIG et.al.)

>Since we're still touting the utility of having an intermediate make a
>decision about what it wants to send to a stub based on the intermediate's
>understanding of security, we need to pick a consistent understanding of
>that security.  (In other words, the application we're concerned with here
>is the stub side server of the validating resolver).

Or we make use of the CD bit.  In early workshops (about 10 years ago 
I mean) we ran into the problem that not all computers agreed on the 
current time.  (NTP wasn't as widespread as it is now.)  The way 
around that at the time was to use the CD bit and get the answer as 
it passed through from the source.

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

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

--
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: Ben Laurie <[email-masked]>
Date: Mon, 13 Oct 2008 06:36:02 +0100

Edward Lewis wrote:
> 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).

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

---

From: Michael StJohns <[email-masked]>
Date: Mon, 13 Oct 2008 07:38:16 -0400

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

---

From: Wouter Wijngaards <[email-masked]>
Date: Mon, 13 Oct 2008 14:16:52 +0200

Hi Michael,

I think it is much simpler than that. The application is interested in
what is known with certainty.
1. It is certain the data is valid (secure)
2. It is certain that security checks failed (bogus)
3. whatever (insecure).

Thus, your numbers 1, 3, 5 are folded into insecure (or maybe more
accurately, 'no security available').

A mail application could deliver 1 and 3, but not 2(bogus).  Or it might
examine the AD bit on replies and only deliver 1.

When a DNAME or CNAME chain crosses a BOGUS entry, the DNAME or CNAME
chain result is bogus. When a DNAME or CNAME chain has all items secure,
the DNAME or CNAME chain result is secure.  All other cases are insecure
(i.e. the chain has one insecure element and the other elements are
insecure or secure).

I do not think a 'must be secure' bit is needed.  Only when all items in
the chain are secure is the result secure, and does the AD bit get set.

Best regards,
   Wouter

---

From: Ben Laurie <[email-masked]>
Date: Mon, 13 Oct 2008 13:15:27 +0100

Michael StJohns 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.
>>>  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.
>>> 
>>> 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.
>> 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).
> 
> 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".
> 
> 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.

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.

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

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

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

> Should a downstream receiver do anything special for messages marked
> as above?  Would this ever be a reasonable filtering criteria?
> 
> 
> 
>> -- http://www.apache-ssl.org/ben.html
>> http://www.links.org/
>>

---

From: Alex Bligh <[email-masked]>
Date: Mon, 13 Oct 2008 14:41:52 +0100

> 2. It is certain that security checks failed (bogus)

One of the merits of Ben's list was it attempted to list the states "as
a user might see them" without associating them in the first instance
to the workings and terminology of the protocol.

>From the user's point of view, I think you (and, I think Ben) have missed
at least one. Using your numbering above here is what a DNSSEC aware
application might find when looking up the name:

1. We have data, which we know is correct & secure (DNSSEC signatures
   verify)
2. We have data, which we know is invalid (DNSSEC shows insecure)
3. We have data, but we are uncertain as to the correctness of the
   data (e.g. no DNSSEC information for that zone, or missing DLV
   or whatever).
4. We have no data, e.g. we got a SERVFAIL. As I understand, we can't
   tell this is secure or not (willing to be corrected here).

Non-DNSSEC-aware resolver stacks return (3) or (4).

As far as I can tell, treating (2) like (4) at the application layer
seems sensible (i.e. I can't see any/many applications distinguishing) (*).
However, an application might handle (1), (3) and [(2)/(4)] at least
as different states (even if only colouring a browser address bar
yet another shade of the rainbow). Compatibility reasons suggest
that legacy applications (non-DNSSEC aware) get to treat (1) and (3)
the same, or every such application will fail when a DNSSEC compliant
library is installed. Given evidence to date suggests adoption of
DNSSEC will be non-instantaneous, this seems mandatory.

(*) interesting nit: state 2 includes secure denial of existence. I am
arguing here secure denial of existence gets treated at the application
layer just like an insecure failure in every circumstance I can think
of. IE, you can spoof a SERVFAIL, DoS the resolver so it times out,
or whatever and it will be treated the same way as a guaranteed denial
of existence through NSEC/NSEC3 at the application layer. I know there
are people who think that maintaining the difference between an
authenticated denial and a failure is useful for more than debugging
purposes, or we wouldn't have spent so long ensuring NSEC's successor
maintained authenticated denial of existence. This implies that they
must see a need for (2) and (4) to be different.

Alex

---

From: Ben Laurie <[email-masked]>
Date: Mon, 13 Oct 2008 14:47:28 +0100

Alex Bligh wrote:
> 
> 
> --On 13 October 2008 14:16:52 +0200 Wouter Wijngaards
> <[email-masked]> wrote:
> 

No.

If I am delivering mail, and the domain does not exist, I bounce it. If
I get SERVFAIL, I hold on to it and try again later.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 13 Oct 2008 09:45:20 -0400

At 7:38 -0400 10/13/08, Michael StJohns wrote:

>...CNAME and DNAME do not have any way of indicating the expected security
>state of the zone to which they point.  ...

Yes they do.  For X CNAME Y, you can determine the security state of 
X by flowing down from the root and you can tell the security state 
of Y by flowing down from the root.  Just as X is not "delegating" to 
Y in the sense of NS's, X is not transferring any security state to 
Y.  X is simply referring to Y. Ditto if this is a DNAME situation.

                                      .               (assume a "signed" root)
                              ------/ | \------
                             /        |        \
                             S        S        S      (S=secure zone)
                             |        |        |
                             S        S        S
                             |        |        |
                             S        U        S      (U=insecure zone)
                             |        |        |
                             X CNAME  Y DNAME  Z
                                               |
                                               W

In this case, X has a secured reference to Y.  Y isn't protected and 
has a rewrite rule to Z.  Z is secured.  You see from inspection from 
a (signed) root down that there is no break in the chain to X and Z, 
but there is the break to Y.

DNSSEC is protecting the querier in that you get to validate what you 
can (where there is data).  But does that help the application?  Not 
really.  This is why I think DNSSEC is there just to benefit the DNS, 
not the application.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Shane Kerr <[email-masked]>
Date: Mon, 13 Oct 2008 15:55:59 +0200

Ben,

> would be to treat it like state 4, I think, but there's room for debate.

I think there are some applications who are willing to accept a "broken"
answer. For instance, if I am going to use an application level
certificate, then I would probably choose to accept a RR with an expired
signature (perhaps bounded in some way) rather than fail a connection
completely.

I think some way to expose this information to the application layer
would be good, so the application layer could make informed decisions
when this makes sense.

--
Shane

---

From: Alex Bligh <[email-masked]>
Date: Mon, 13 Oct 2008 15:18:20 +0100

Ben,

> I get SERVFAIL, I hold on to it and try again later.

Ah yes. Agreed. So that makes the states:

1. We have data, which we know is correct & secure (DNSSEC signatures
   verify)
2. We have data, which we know is invalid (DNSSEC signature failure)
3. We have data, but we are uncertain as to the correctness of the
   data (e.g. no DNSSEC information for that zone, or missing DLV
   or whatever).

4. We have a failure, e.g. we got a SERVFAIL. As I understand, we can't
   tell this is secure or not (willing to be corrected here).

5. We have no data, and the absence of data is correctly authenticated
   (e.g. by NSEC/NSEC3)
6. We have no data, but the response is invalid (DNS signature failure
   on NSEC/NSEC3 proof of denial of existence)
7. We have no data, but we are uncertain as to its correctness (e.g.
   NXDOMAIN in vanilla DNS)

I think 2 and 4 in the above are (at an application layer) the same,
in that if I spoof by sending bogus answers, that should result in
the same action as DoS and timeout, or spoofing SERVFAIL or whatever.
That would suggest treating 6 the same as these two as well.

By the same logic that a non-DNSSEC-aware application should treat
1 and 3 the same, it should treat 5 and 7 the same I presume.

Alex

---

From: Edward Lewis <[email-masked]>
Date: Mon, 13 Oct 2008 10:57:30 -0400

>   data (e.g. no DNSSEC information for that zone, or missing DLV

DNSSEC says nothing about "correctness." If the IP address is typed 
wrong by the zone admin, DNSSEC will sign the result.

"Missing DLV" is something that cannot be diagnosed from the packet 
arriving on port 53.  If you have no trust anchor for a name and you 
get signed data owned by that name, it is indistinguishable whether 
the name has a key and you don't know it ("missing DLV") versus 
someone inserting falsely signed data just so you deduce it is 
missing.

DNSSEC only says "this answer looks good" or "doesn't look good." 
Trying to figure out whether the answer's disposition is 
temporary/permanent, correct/incorrect, trustworthy/not takes more 
than just the DNS data and more than just the query at hand.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 13 Oct 2008 08:08:38 -0700

> somewhat orthogonal to the DNS states:

Possibly:

6:  Leap-of-faith.  Its "unknown" but its the same trust anchor that I  
have previously seen for this domain at some long time previously.

7:  Leap-of-faith failure.  Its "unknown" and different from the first  
time I've seen the trust anchor for this domain.

> to be a reasonable approach.

The problem with relying on end-application validation of the states  
is that there is really only three possible answers, and none of them  
really rely on the detailed answers that the resolver gives:

1: The network is not trusted by the application, thus you need to  
verify end-to-end the other side.

Once the application makes this decision, DNS for purposes of name- 
 >address mapping is irrelevant for security purposes, although DNSSEC  
does matter if you care about a name->public_key mapping because you  
are using DNSSEC as a CA instead of any other CA or leap-of-faith key- 
exchange mechanisms.

2: The Network is trusted by the application.

Once the application makes this decision, it might as well accept  
everything as long as the resolver implements the defenses against OUT- 
of-path attacks, which is orthoginal to what you do in several of the  
key-failure corner-cases.

3:  The Network is trusted by the application, but the recursive  
resolver belonging to the ?ISP? isn't.  (The Rogue resolution- 
authority problem)

IF the application makes this decision, it should simply use its own  
non-DNSSEC recursive resolver to make queries and bypass the external  
recursive resolver altogether, because such a recursive resolver can  
always just say "uhh, no DNSSEC here".

---

From: Alex Bligh <[email-masked]>
Date: Mon, 13 Oct 2008 16:33:24 +0100

--On 13 October 2008 10:57:30 -0400 Edward Lewis <[email-masked]> 
wrote:

> DNSSEC says nothing about "correctness." If the IP address is typed wrong
> by the zone admin, DNSSEC will sign the result.

Sorry - I was using 'correct' as a term without any prior terminological
commitments to mean "not only is there data but it is signed but all the
signatures match" (I believe this corresponds to DNSSEC's 'secure' status
but that also covers for instance secure denial).

> arriving on port 53.  If you have no trust anchor for a name and you get
> signed data owned by that name, it is indistinguishable whether the name
> has a key and you don't know it ("missing DLV") versus someone inserting
> falsely signed data just so you deduce it is missing.

My point was that it is (I think) possible to distinguish between faults
where a resolver cannot verify a signature presented (e.g. signature
added promiscuously to signed data, no trust anchor found) and where
the signature doesn't match the data (e.g. data tampered with on the
wire).

In the former case (number 3 in my email), it seems to me one
doesn't know whether the signature is added as some form of attempted
attack (where one might think one should trust the data less) or whether
one just doesn't have the right trust anchors configured (where one
might think one should just treat the data as if it weren't signed
at all), so treating the data as if it were unsigned (the rest of
my case 3) seems fine.

In the latter class of errors, there is no proper explanation for that,
and best ignore the data entirely.

> DNSSEC only says "this answer looks good" or "doesn't look good." Trying
> to figure out whether the answer's disposition is temporary/permanent,
> correct/incorrect, trustworthy/not takes more than just the DNS data and
> more than just the query at hand.

I was under the misapprehension that this was precisely what this thread
was concerned with! DNSSEC doesn't only say the answer looks good, or
does not look good. It also occasionally fails entirely (e.g. SERVFAIL).
Further, a DNSSEC aware resolver will also occasionally give results
found through vanilla (non-DNSSEC) DNS. That, plus there is clearly a
differentiation between results and no results for a DNSSEC aware
version of (e.g.) gethostbyname.

Alex

---

From: Michael StJohns <[email-masked]>
Date: Mon, 13 Oct 2008 12:14:46 -0400

>1? (Oh, I do now, having read below more carefully)

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

>We should actually figure out what all the distinct states are, rather

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.

>For most people transitioning to DNSSEC, then I'd treat this as a

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

>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

---

From: Michael StJohns <[email-masked]>
Date: Mon, 13 Oct 2008 12:23:25 -0400

At 08:16 AM 10/13/2008, Wouter Wijngaards wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi Michael,
>

This is why doing the bigger matrix and trying to do the decomposition into handling states is probably the right approach - your later email changes this based on further discussion but still doesn't quite get all the states covered.

>the chain are secure is the result secure, and does the AD bit get set.

The AD bit gets set (or not) when you return data from a recursive nameserver, but that doesn't really describe how an application doing its own DNSSEC validation should handle this type of data.

It may be that your approach of if anything is bogus its all bogus, else if everything is secure its all secure, else its unsecure is correct.  BUT - this seems at odds with the general DNSSEC contract that says we don't transition to an unsecure state unless we do it securely.  If I'm the zone owner of the zone with the DNAME, and I'd doing a reference to another zone that - at the time I did the delegation - I knew to be secure, shouldn't I expect that DNSSEC should flag it if someone tries to resolve this and finds an unsecure zone?  Again if not, why not?  And why isn't this as much of a downgrade attack as all the other various schemes that have been described to me?

Mike

>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.9 (GNU/Linux)
>
>iEYEARECAAYFAkjzPDQACgkQkDLqNwOhpPg4hgCfZJrXXhwSeXgeZiU9W4FZ5Wwi
>O84AoKnIBWKPbaVGzxeCueQWk5L0WslT
>=tjtc
>-----END PGP SIGNATURE-----

---

From: Michael StJohns <[email-masked]>
Date: Mon, 13 Oct 2008 12:30:56 -0400

Hi Ed -

I agree that you can determine the security state of X and the security state of Y by examining trust anchors, dlv etc.  But that's not the question.  The question is "What is the security state of the compound answer XY?"

 From Marc Andrew's and somewhat from Wouter's email, it could be a new state "unauthenticated" - because the response out of an intermediate resolver is to return the data but not set the AD bit.  I say new, because it's different than unknown, secure,  and bogus and wouldn't be returned for the same reasons that you would return it for unsecure data under a single trust anchor.  But even that begs the question of what an application should do with it.

Later, Mike

At 09:45 AM 10/13/2008, Edward Lewis wrote:
>Yes they do.  For X CNAME Y, you can determine the security state of X by flowing down from the root and you can tell the security state of Y by flowing down from the root.  Just as X is not "delegating" to Y in the sense of NS's, X is not transferring any security state to Y.  X is simply referring to Y. Ditto if this is a DNAME situation.
>
>
>In this case, X has a secured reference to Y.  Y isn't protected and has a rewrite rule to Z.  Z is secured.  You see from inspection from a (signed) root down that there is no break in the chain to X and Z, but there is the break to Y.
>
>DNSSEC is protecting the querier in that you get to validate what you can (where there is data).  But does that help the application?  Not really.  This is why I think DNSSEC is there just to benefit the DNS, not the application.
>--

---

From: Michael StJohns <[email-masked]>
Date: Mon, 13 Oct 2008 12:38:20 -0400

At 10:57 AM 10/13/2008, Edward Lewis wrote:
>DNSSEC only says "this answer looks good" or "doesn't look good." Trying to figure out whether the answer's disposition is temporary/permanent, correct/incorrect, trustworthy/not takes more than just the DNS data and more than just the query at hand.

DNSSEC says the answer looks good - SECURE
or doesn't look good - BOGUS 
or DNSSEC told me I shouldn't care about DNSSEC past some point - UNSECURE
or I have no information which would let me determine what DNSSEC thinks about the data - UNKNOWN

"Trustworthy" begs a definition here for what "looks good" means in relationship to "trusting" DNS data.

---

From: Michael StJohns <[email-masked]>
Date: Mon, 13 Oct 2008 12:45:50 -0400

Sorry - note in line

>This is why doing the bigger matrix and trying to do the decomposition into handling states is probably the right approach - your later email changes this based on further discussion but still doesn…

.... confused you with a later email by Alex.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 13 Oct 2008 12:44:43 -0400

At 12:30 -0400 10/13/08, Michael StJohns wrote:
>Hi Ed -
>
>I agree that you can determine the security state of X and the security
>state of Y by examining trust anchors, dlv etc.  But that's not the question.
>The question is "What is the security state of the compound answer XY?"

The security state - in the eyes of DNS that is easy.  If the X 
passes the DNSSEC test, Y passes the test as being unsigned, and Z 
passes the DNSSEC test, the answer is "AD."  IOW, there's nothing 
suspicious about the result as far as the DNS is concerned.

It's fair to ask though "what's the value" of piecemeal checking.  My 
answer is that "it's out of scope" for DNS.

>  From Marc Andrew's and somewhat from Wouter's email, it could be a new
>state "unauthenticated" - because the response out of an intermediate resolver
>is to return the data but not set the AD bit.  I say new, because it's
>different than unknown, secure,  and bogus and wouldn't be returned for the
>same reasons that you would return it for unsecure data under a single trust
>anchor.  But even that begs the question of what an application should do
>with it.
>
>Later, Mike

After the debate in Winter 2001 (SLC IETF) over the AD bit not being 
tied to cryptography, I'd set the AD bit in the response.  I(f i)t's 
authenticated to the responding server.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Michael StJohns <[email-masked]>
Date: Mon, 13 Oct 2008 13:07:11 -0400

At 12:44 PM 10/13/2008, Edward Lewis wrote:
>The security state - in the eyes of DNS that is easy.  If the X passes the DNSSEC test, Y passes the test as being unsigned, and Z passes the DNSSEC test, the answer is "AD."  IOW, there's nothing suspicious about the result as far as the DNS is concerned.

You sure about that answer?  Pretend all you're doing is looking up Y.  Since Y is UNSECURE,  shouldn't you get an answer with the AD bit cleared? So shouldn't the compound answer also clear the AD bit?

Let's go a bit further.  Let's say that the validating intermediate resolver queried without the CD bit set gets SECURE, UNSECURE and BOGUS for the three legs of the triad.  Should it return the SECURE and UNSECURE parts and also do a SERVFAIL?  RFC 4035 - 5.5 is unclear on this:

>5.5.  Resolver Behavior When Signatures Do Not Validate
>
>   If for whatever reason none of the RRSIGs can be validated, the
>   response SHOULD be considered BAD.  If the validation was being done
>   to service a recursive query, the name server MUST return RCODE 2 to
>   the originating client. 

*SOME* of the RRSIGs can be validated... *sigh*  Does the response still return an RCODE 2?

>It's fair to ask though "what's the value" of piecemeal checking.  My answer is that "it's out of scope" for DNS.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 13 Oct 2008 13:55:27 -0400

>relationship to "trusting" DNS data.

This is the kind of debate that'll never end, judging from past 
incarnations of this thread.  To me, an answer that is under a trust 
anchor and below a null DS set is "looks good" as far as DNSSEC is 
concerned.  I.e., to me, UNSECURE == SECURE == UNKNOWN, when I 
consider the "bottom line" of the query-response.  I guess I have a 
Machiavellian (ends justify the means, i.e., all that matters are the 
ends) streak in me.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Ben Laurie <[email-masked]>
Date: Mon, 13 Oct 2008 21:35:39 +0100

Edward Lewis wrote:
> concerned.  I.e., to me, UNSECURE == SECURE == UNKNOWN, when I consider
> the "bottom line" of the query-response.  I guess I have a Machiavellian
> (ends justify the means, i.e., all that matters are the ends) streak in me.

Broadly I agree, except I think you can also choose BOGUS == UNSECURE ==
UNKNOWN.

i.e. either trust everything that isn't bogus, or trust everything that
is secure.

Anyone who wants anything more nuanced than that can (and will, anyway)
write their own s/w :-)

Cheers,

Ben.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 14 Oct 2008 10:19:41 -0400

I'll apologize, the indenting of quotes isn't working, so if I jumble 
up what I'm replying to...

At 13:07 -0400 10/13/08, Michael StJohns wrote:
>You sure about that answer?  Pretend all you're doing is looking up Y.
>Since Y is UNSECURE,  shouldn't you get an answer with the AD bit cleared?
>So shouldn't the compound answer also clear the AD bit?

Back in 2001 Brian and I went on and on about the meaning of the AD 
bit.  To me it meant that the DNSSEC process had been completed and 
we were happy.  He said that "we were happy."  The point of 
contention was how an authoritative server set the bit.

In the first generation, authoritative servers would validate all 
records as they were read from the zone file or via XFR.  (I forget 
how we dealt with dynamic update then.)  This practice got quite 
onerous and Brian decided it wasn't worth the effort as "well, if you 
can't trust your own filesystem you are hosed."

I'm pinning this as Brian vs. me, but I'm just doing that for the drama.

Well, he and I went at it for 100+ messages.  Finally he won - the AD 
bit meant that the answering server was happy with what it was giving 
back. An AD bit and a TSIG to the server was all a stub should need - 
i.e., TSIG says "I trust you" and the AD bit said "well, the one I 
trust is happy, ergo I am happy."

So - if X and Z are signed and validated and Y is determined to not 
have any possible chance at being validated, all three are "happy" 
states and the AD bit ought to be set.

I realize that there is a boat load of security professionals that 
are uncomfortable with the notion that you can declare something 
checked if there is nothing to check.  That represented my position 
in the thread long ago.  Truth is, the world is not as the security 
folks see.

Most folks are "innocent until proven guilty" types, not "guilty 
until proven innocent."  And that was reflected in the result of the 
thread and the RFC 3655 (obsoleted by the last round of DNSSEC RFCs).

Let's go a bit further.  Let's say that the validating intermediate 
resolver queried without the CD bit set gets SECURE, UNSECURE and 
BOGUS for the three legs of the triad.  Should it return the SECURE 
and UNSECURE parts and also do a SERVFAIL?  RFC 4035 - 5.5 is unclear 
on this:

I don't think it matters what you choose to do, i.e., 
per-implementation choice won't violate interoperability.

If a server replies with just X and Y (as SECURE and UNSECURE), the 
querier would realize the answer is not complete and have to go off 
and try to get Z (BOGUS) and see a SERVFAIL.  IF the server 
immediately gives back a SERVFAIL, you save a round trip but the 
querier won't get the SECURE and UNSECURE X and Y.

5.5.  Resolver
Behavior When Signatures Do Not Validate

    If for whatever reason none of the RRSIGs can be validated,
the
    response SHOULD be considered BAD.  If the validation
was being done
    to service a recursive query, the name server MUST return
RCODE 2 to
    the originating client.

*SOME* of the RRSIGs can be validated... *sigh*  Does the response 
still return an RCODE 2?

It's not meant to be interpreted as "some is the opposite of none" 
but "none" versus "at least one (chain) works."  The problem is that 
this section is deficient - it only thinks of looking for X (no 
consideration of CNAME or DNAME).  The text needs to be rewritten to 
handle CNAME and DNAME (or any other lookup altering) processing.

This ought to be marked as an issue for the DNSSECbis document.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Tue, 14 Oct 2008 10:26:05 -0400

>Broadly I agree, except I think you can also choose BOGUS == UNSECURE ==

Such a strategy is akin to (today) only using IPv6. ;)  That is, most 
of the network is not doing DNSSEC and not doing IPv6.

Equating SEURE, UNSECURE, and UNKNOWN is what I think is more to the 
spirit of DNSSEC and incremental deployment.  It's a recognition that 
what can be secure is but you still have access to the legacy network.

Equating BOGUS, UNSECURE, and UNKNOWN is a paranoid strategy, only 
trusting what you can see and touch.

In some circles I can understand the paranoia.  But most of the 
economy needs open access and a willingness to accept risk.

>Anyone who wants anything more nuanced than that can (and will, anyway)

I hope they also realize they are a, umm, niche market... ;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Ben Laurie <[email-masked]>
Date: Tue, 14 Oct 2008 15:36:14 +0100

Edward Lewis wrote:
> Such a strategy is akin to (today) only using IPv6. ;)  That is, most of
> the network is not doing DNSSEC and not doing IPv6.
> 
> In some circles I can understand the paranoia.  But most of the economy
> needs open access and a willingness to accept risk.

In other words: you agree that you can also choose it.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 14 Oct 2008 10:49:49 -0400

>In other words: you agree that you can also choose it.

You can choose whatever you want whenever you want.  Local policy 
always trumps all other policies.

There's what I would recommend for "general purpose implementations" 
and then there is what I would implement for turnkey implementations. 
All that matters is that they ultimately interoperate and still meet 
each situation's needs.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 14 Oct 2008 08:21:56 -0700

On Oct 14, 2008, at 7:26 AM, Edward Lewis wrote:

> Such a strategy is akin to (today) only using IPv6. ;)  That is,  
> most of the network is not doing DNSSEC and not doing IPv6.
>
> spirit of DNSSEC and incremental deployment.  It's a recognition  
> that what can be secure is but you still have access to the legacy  
> network.
>

Then why not the following:

DNSSEC has two uses:  Secure name lookup, and as Another CA  
Infrastructure Run By Verisign Combined With A Hierarchical  
Distributed Integrity Data Store for small datums.  For "Another CA  
Infrastructure", the end application needs full control and full  
information, and a much richer API then gethostbyname().

But for secure name lookup, DNSSEC's additional protection is against  
in-path adversaries.  The adversary on the wire is not a real concern  
to my mind for DNS (its a concern for the end application).

But as witnessed by David Dagon's work, ISP's which wildcard failures,  
and even legitimate sites like OpenDNS man-in-the-middling some names  
( dig www.google.com @208.67.222.222 ), the recursive resolver IS an  
in-path adversary and a serious concern.

Thus why not the following default policy:  If the host's stub  
resolver is actually caring about DNSSEC ("secure name lookup"),  
operate in the following mode:

a)  If the stub resolver can fully validate a complete signature chain  
for the record returned from the recursive resolver, accept it, cache  
it, return it for gethostbyname() and have a nice day.

b)  If, FOR ANY REASON, the stub resolver can not fully validate the  
complete signature chain (expired signature, bad signature, recursive  
resolver lying, recursive resolver stating "What's DNSSEC d00d?"), it  
conducts a complete recursive fetch of its own to get the value to be  
returned to the querying application, and does not cache any record  
that doesn't have a valid signature.

This way, all failures of DNSSEC (or failure to USE DNSSEC) will still  
resolve, and, as importantly, they will resolve over what will be  
effectively the same path for in-path adversaries as the application  
will face.

I will argue that this is the correct behavior, because any  
application which would trust the name is probably vulnerable to the  
MitM anyway, so you haven't increased the vulnerability to the end  
application generating the query, but did not act as a denial-of- 
service attack because of a signature failure.

---

From: Michael StJohns <[email-masked]>
Date: Wed, 22 Oct 2008 20:54:26 -0400

After thinking about this topic for a while, I'm still bothered by the inconsistency of treatment here.

But I think I have a possible mechanism - at least for DNAME.

DNAME is the pretty much the equivalent of a delegation - only sideways.    Why not treat it like any other delegation?  In other words, in addition to the records currently permitted at a DNAME node, add DS to the list.  This would require slightly overloading the meaning of DS, but in a way that doesn't break the model too much.

If a DNAME node does not have at least one corresponding DS record (proven by NSEC/NSEC3), the validation rules are exactly the same as if you'd not included a DS for a subordinate delegation. E.g. no DNSSEC is expected in the target zone.

Since one of either DNAMEs or NS records can be present at a node (I think that's correct), the interpretation of the DS record is dependent on which of these two is present.  If the type is DNAME, the DS record points to a DNSKEY record at the target name and the chain has to continue from there.

This gets away from the problem where a resolver has one trust anchor, but doesn't have a trust anchor for the target zone at the cost of requiring some administration of the DS at the DNAME.

Continuing the logic from above, if you get a unsecure DNAME delegation (i.e. DNAME without DS), you *stop* doing DNSSEC validation.  It doesn't matter if you have trust anchors for any further targets - the validation answer is UNSECURE.  This is required for consistency - different resolvers have different sets of trust anchors.  It's not all that coherent to get BOGUS from one, UNSECURE from another and UNKNOWN from a third if you can avoid it.  Chaining security back to the original trust anchor and evaluating security in terms of data that chains back ONLY to that trust anchor seems to be the most consistent approach.

In any event, I think this is at least somewhat backwards compatible. 

Let the mud slinging begin... :-)

Mike

---

From: Mark Andrews <[email-masked]>
Date: Thu, 23 Oct 2008 14:43:24 +1100

In message <[email-masked]>, Michael StJohns writes:
> DNAME is the pretty much the equivalent of a delegation - only sideways.    W
> hy not treat it like any other delegation?  In other words, in addition to th
> e records currently permitted at a DNAME node, add DS to the list.  This woul
> d require slightly overloading the meaning of DS, but in a way that doesn't b
> reak the model too much.
> 
> If a DNAME node does not have at least one corresponding DS record (proven by
> NSEC/NSEC3), the validation rules are exactly the same as if you'd not inclu
> ded a DS for a subordinate delegation. E.g. no DNSSEC is expected in the targ
> et zone.
> 
> Since one of either DNAMEs or NS records can be present at a node (I think th
> at's correct), the interpretation of the DS record is dependent on which of t
> hese two is present.  If the type is DNAME, the DS record points to a DNSKEY 
> record at the target name and the chain has to continue from there.

	So I create a DNAME pointing into a zone I don't own and
	add a DS pointing to a forged DNSKEY.  This DNSKEY is then
	marked as trusted and I now have control of a zone I don't
	own.

> This gets away from the problem where a resolver has one trust anchor, but do
> esn't have a trust anchor for the target zone at the cost of requiring some a
> dministration of the DS at the DNAME.
>
> Continuing the logic from above, if you get a unsecure DNAME delegation (i.e.
> DNAME without DS), you *stop* doing DNSSEC validation.  It doesn't matter if
> you have trust anchors for any further targets - the validation answer is UN
> SECURE.  This is required for consistency - different resolvers have differen
> t sets of trust anchors.  It's not all that coherent to get BOGUS from one, U
> NSECURE from another and UNKNOWN from a third if you can avoid it.  Chaining 
> security back to the original trust anchor and evaluating security in terms o
> f data that chains back ONLY to that trust anchor seems to be the most consis
> tent approach.

	There are only three possible outputs from a validating resolver.

	The *all* of the answer and authority sections are SECURE (ad=1).

	All of the answer and authority sections passed validation (got
	SECURE or INSECURE) and some part was INSECURE (ad=0).

	Validation failed for some part and you get SERVFAIL.

	There is no UNKNOWN output.  Records without a trust anchor are
	INSECURE.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Michael StJohns <[email-masked]>
Date: Thu, 23 Oct 2008 00:26:18 -0400

>        marked as trusted and I now have control of a zone I don't

I think you're confusing how you might implement this with what I actually said.

When doing this, you have to do the analysis first for the non-cached approach.  Where you do all the validations and lookups from the beginning.  THEN think about how you cache the data to keep from polluting trust states.

For caching, you only mark the apex DNSKEY (and its subordinate data) of the target zone as trusted ONLY for queries that are referred in via the off-tree DNAME and DS.  If you come at it any other way you don't trust the data unless you have a superior trust anchor.  (Yup I know - more cruft, but relative to DNSSEC probably not a great portion of the cruft).

 Let's say the recursive validating resolver doesn't have a superior trust anchor for the target - a direct query for the target gets the data with an output state of unknown/unsecure.  An indirect query via the DNAME - assuming the target is signed and the DS chain validates - has the possibility of getting data with an output state of secure - or for that matter bogus (in which case no data or partial data is returned).

If you do have a configured trust anchor for the target zone and that validation doesn't match the DS referral from the DNAME - well - that's probably one of the BOGUS cases.  If you don't have a configured trust anchor for the target zone, umm... then the owner of the DNAME can steer you pretty much wherever he wants - even a zone that's somewhere that doesn't have a trust anchor so how is this worse?

You are correct that if you implement this so the resolver takes the indirect trust and caches it as absolute trust then the owner of any DNAME under any trust anchor can pollute the trust cache on that resover.  So don't implement it this way.... 

>        There is no UNKNOWN output.  Records without a trust anchor are

There's a difference between the output from a validator and the output from a validating resolver - but I digress...

We're just going to have to agree to disagree.  I can distinguish between data where I have no information about its trust state (it might be signed, but I have NO trust anchor so I have no way of determining whether it is secure unsecure or bogus) and data where I have information about its trust state (because I have a trust anchor and I was able to run a validator and return one of secure, unsecure or bogus on the provided data).   That difference may or may not be important to an end-application validator - but I'm not willing to exclude it from consideration at this point.  So mentally from now on just substitute UNSECURE wherever I say UNKNOWN and I'll consider the protest given proforma.... :-)

---

From: Wouter Wijngaards <[email-masked]>
Date: Thu, 23 Oct 2008 09:30:38 +0200

Hi Michael,

You can propose some new mechanism here, but do not overload the DS
semantics more. Get a new type code, like DLV did.

That said, lets sling some mud :-)

>>> d require slightly overloading the meaning of DS, but in a way that doesn't b

So you want the owner of the DNAME to indicate if he is referring to a
secured zone or not (using a hash of a key).  And the validator can then
check if the destination is really secure.  This needs only one bit:
target of redirection is supposed to be secure yes/no.

The chain of trust runs parralel to the delegation hierarchy, and I
think sideways chains of trust need not enter the picture here.  Not for
your DNAME concerns.

Although the above is what I think you want.  I think the current DNAME
situation is fine.  The resolver can see if the target of a DNAME
redirection is secure or not based on trust anchors, and is going to set
the security result of the entire DNAME-chain to the lowest security
encountered anyway.

>>> dministration of the DS at the DNAME.

Yeeks how to keep that DS up to date.  Better one bit: target secure, it
does not suffer from key rollover.

>>        There is no UNKNOWN output.  Records without a trust anchor are

I agree with Mark here.

No.

You see when a validator encounters a securely-insecure delegation, I
mean a proof that a DS is absent.  Then it knows that the remainder is
not signed with a chain of trust from the trust anchor that it has been
following.  However, the result is simply insecure, and not somehow
magically more secure that a result obtained without a trust anchor at
all.  What is the extra security afforded by a securely insecure
delegation?  The result is as prone to modification as a result obtained
for a domain without trust anchor.

Of course, the two domain set ups have a different operational
configuration.  So although you can give them different names (which can
be useful for other things, such as operator debugging), they have the
same level of security.

Cheers,
   Wouter

---

From: Edward Lewis <[email-masked]>
Date: Thu, 23 Oct 2008 11:27:53 +0200

>inconsistency of treatment here.

What inconsistency?

>DNAME is the pretty much the equivalent of a delegation - only sideways.
>Why not treat it like any other delegation?  In other words, in addition to
>the records currently permitted at a DNAME node, add DS to the list.
>This would require slightly overloading the meaning of DS, but in a way
>that doesn't break the model too much.

This makes as much sense as "matrix management."  DNAME isn't a 
delegation, it's a query restart.  What if the DNAME says there is a 
DS for the target but following the tree down to the target has no 
DNAME?

>This gets away from the problem where a resolver has one trust anchor, but
>doesn't have a trust anchor for the target zone at the cost of requiring
>some administration of the DS at the DNAME.

This is not a problem.  If the target of the DNAME is not DNSSEC 
protected, it doesn't matter to the DNS.  The application maybe, but 
what can it do?  If the target administrator has not signed the zone, 
then the application simply cannot validate the answer via DNSSEC.

>another and UNKNOWN from a third if you can avoid it.  Chaining security back
>to the original trust anchor and evaluating security in terms of data that
>chains back ONLY to that trust anchor seems to be the most 
>consistent approach.

I think you are expecting too much from DNSSEC.

Thinking about this scenario, if your application really needed 
security like this, why would there be the situation of secure DNAME 
insecure DNAME secure?  Although this flip-flop may happen, will it 
happen where it matters?  Is it realistic?  Or are we whacking with a 
sledgehammer at a shadow?

---

From: Ben Laurie <[email-masked]>
Date: Thu, 23 Oct 2008 11:59:45 +0100

Michael StJohns wrote:
> DNAME is the pretty much the equivalent of a delegation - only
> sideways.    Why not treat it like any other delegation?  In other
> words, in addition to the records currently permitted at a DNAME
> node, add DS to the list.  This would require slightly overloading
> the meaning of DS, but in a way that doesn't break the model too
> much.
> 
> If a DNAME node does not have at least one corresponding DS record
> (proven by NSEC/NSEC3), the validation rules are exactly the same as
> if you'd not included a DS for a subordinate delegation. E.g. no
> DNSSEC is expected in the target zone.
> 
> Since one of either DNAMEs or NS records can be present at a node (I
> think that's correct), the interpretation of the DS record is
> dependent on which of these two is present.  If the type is DNAME,
> the DS record points to a DNSKEY record at the target name and the
> chain has to continue from there.
> 
> This gets away from the problem where a resolver has one trust
> anchor, but doesn't have a trust anchor for the target zone at the
> cost of requiring some administration of the DS at the DNAME.
> 
> Continuing the logic from above, if you get a unsecure DNAME
> delegation (i.e. DNAME without DS), you *stop* doing DNSSEC
> validation.  It doesn't matter if you have trust anchors for any
> further targets - the validation answer is UNSECURE.  This is
> required for consistency - different resolvers have different sets of
> trust anchors.  It's not all that coherent to get BOGUS from one,
> UNSECURE from another and UNKNOWN from a third if you can avoid it.
> Chaining security back to the original trust anchor and evaluating
> security in terms of data that chains back ONLY to that trust anchor
> seems to be the most consistent approach.
> 

I don't understand the rationale behind all this complication.

If I chose to point a DNAME at an unsecured domain, then that was my
choice, and I should live with it. If I don't want the domain to be
unsecured, then I should either not delegate to it, or ensure it is
secured by non-protocol means (e.g. by owning the domain myself, by
contract, by sufficient purchase of beer for the domain owner, etc.)

---

From: Michael StJohns <[email-masked]>
Date: Thu, 23 Oct 2008 12:25:06 -0400

>contract, by sufficient purchase of beer for the domain owner, etc.)

Hi Ben -

One of the problem we get with DNS is that there are two views of the data (at least) - the publisher's, and the resolver's views. DNSSEC makes this more complicated by the presence or absence of certain trust anchors.

As publisher, I have a signed domain, and as publisher, I publish a DNAME also pointing at a signed domain.  I've done my due diligence as you suggest - I even own the target zone.

As resolver, I get a trust anchor for the first domain (more probably for a parent of the domain), but I don't have any a priori information that the target domain is also signed (or even that I had a redirect to that zone), so I don't know to get a trust anchor for it.  There's no way of encoding in DNS/DNSSEC the publishers security intentions with respect to the complete DNAME chain.  This leads to the problem where the publisher thought it was delegating into a signed zone, but the resolver thought the zone was unknown (no superior trust anchor).  The resolver has no way of telling that the publisher really thought this zone was signed and that the resolver should return a BOGUS answer if the target zone wasn't.

Answering Ed's question about inconsistency here: In a resolution without indirect records (e.g. DNAME, CNAME, MX, etc), the resolvers expectation about the security state of the answer are originally set by the presence or absence of a trust anchor and, assuming the trust anchor is present, that expectation changes only upon proof that it should (e.g. signed delegation into unsigned zone).  With DNAME, once the resolver starts doing lookups in the target zone, it restarts its expectation of the state of the answer based on what it knows about trust anchors for the target.  There is no chain of proof possible from the DNAME zone to the target zone in this model.

My suggestions are an attempt to provide a chain of proof from the original trust anchor (provided by the DNAME publisher or its parent) through to the final answer.  If that chain of proof validates, the resolver can say something useful about the entire answer chain  and the final answer and I think that's the only case in which this is true.  The case where the resolver just happens to have trust anchors for the DNAME zone and all of the target zones says useful things about each individual zone lookup, but not about the compound answer (I can elaborate here about DNAME publisher expectations and target zone publisher actions if necessary).

---

From: Michael StJohns <[email-masked]>
Date: Thu, 23 Oct 2008 12:37:41 -0400

>>inconsistency of treatment here.

See my note to Ben.

>This makes as much sense as "matrix management."  DNAME isn't a delegation, it's a query restart.  What if the DNAME says there is a DS for the target but following the tree down to the target has no DNAME?

I'm not sure what you're getting at here.  DNAMEs point off tree.  So if I have

foo.example.com  DNAME otherexample.com
foo.example.com DS <ds data>
foo.example.com NSEC [DNAME, DS] <target>

otherexample.com  DNSKEY <data pointed to by the DS>
otherexample.com  <rest of the RRs>

DNAME says go look at another zone.
DS says here's how you bridge the trust.

If you're saying, what happens if you do a DNAME to a name subordinate to the DNAME - isn't that one of those illegal cases for DNAME?

>This is not a problem.  If the target of the DNAME is not DNSSEC protected, it doesn't matter to the DNS.  

This is a problem.  DNAME publisher thought the target was protected, resolver didn't have trust anchors for it.  

>The application maybe, but what can it do?  If the target administrator has not signed the zone, then the application simply cannot validate the answer via DNSSEC.
>
>>chains back ONLY to that trust anchor seems to be the most consistent approach.
>
>Thinking about this scenario, if your application really needed security like this, why would there be the situation of secure DNAME insecure DNAME secure?  Although this flip-flop may happen, will it happen where it matters?  Is it realistic?  Or are we whacking with a sledgehammer at a shadow?

I used that one as an example to try and figure out what the output state was and got an answer from all of you that was inconsistent with the general contract.  In the case I'm proposing - once you went unsecure - as provide by the DS chain through the DNAME - then you'd stay unsecure, just like you do now with signed delegations into unsigned zones.

---

From: Michael StJohns <[email-masked]>
Date: Thu, 23 Oct 2008 13:17:23 -0400

>semantics more. Get a new type code, like DLV did.

Fair - but the the new record will pretty much have the same syntax and semantics. 

>target of redirection is supposed to be secure yes/no.

I considered this - but that means that you need to ensure that all the resolvers have the second and subsequent trust anchors and that's problematic.  Encoding the chain of trust as part of the DNAME referral means that I as publisher don't have to worry (much) about whether or not the resolver has my target's trust anchor.  

>the security result of the entire DNAME-chain to the lowest security

Yeah, except there's no way of encoding this in a return from a validating recursive resolver to a non-DNSSEC aware stub.  The one bit approach that tells the resolver to block a return unless the entire answer validates (or is securely unsecure) is slightly better, but gets into a coherence issue.

>does not suffer from key rollover.

If I'm DNAMEing to a zone, I'm going to have to set up some protocol for dealing with changes to that zone.  A variant of the trust anchor update stuff would work here.

>for a domain without trust anchor.

It's a fair comment.   Here's why I continue to fight this.  A trust anchor provides two pieces of information:  a public key, and by the mere presence of the trust anchor the initial state of a virtual "zone is signed" bit.  The absence of the trust anchor does not equate to "zone is not signed" but to "resolver doesn't know whether the zone is signed"

Think of it this way, the unknown state is like the X state in ASIC circuitry design.  You may end up treating it as a 0 or 1 at some point, but you have to figure out a way of collapsing it to the 0 or 1 first.  Resolvers basically collapse the X to a 0 - unsecure - because they don't have the ancillary information (trust anchor) to treat it as a 1.  The resolver doesn't know if the zone is signed, but it has no way of proceeding unless it treats the zone as unsigned. The transition from X to 0 is not secure - there's no cryptographic proof to do the state setting.  This differs from a secure transition from secure to unsecure - from 1 to 0 - by doing a signed delegation to an unsigned zone.  

I actually can at some point see some policy wonk requiring that resolvers under the wonk's control will not resolve names unless they are under a trust anchor.  He won't care about the fact that some delegations are to unsecure zones - he's just concerned about getting DNSSEC deployed.  So yes - I still think there's a difference.

While I was going through this exercise of answering your email, Ben's and Ed's I came up with a pretty good example of why I think this (chaining through a DNAME) is necessary.

I work for the example.com company.  My local recursive resolver has been set up with example.com trust anchors.  The example.com zone includes a set of records which describe the SSH fingerprints for those machines.  example.com is sold to otherexample.com and a DNAME record is placed into the system to do the redirect.  My local resolver still only has the trust anchor for example.com.    I go to a new machine asking the "newmachine.example.com" question to retrieve the SSH fingerprint (I'm an old timer - I'm still using old scripts).  I get an answer for the SSH fingerprint and for an A record - which has been cheerfully forged by a data thief.  I go to that machine, update the 10 gig of ssn's, names and birthdates that I'm archiving from a machine I'm about to rebuild.  That machine is somewhere in russia, china, new york, etc... and its not a company machine.

Out of band, I (person, machine whatever) was told I could rely on the data returned from the resolver for security purposes.  (And this is why I've told people over the years that DNSSEC should not be relied upon to validate anything other than DNS data).  My machine was set up with that assumption in mind.  The local resolver is doing what its supposed to do under the current DNAME interpretation.  My machine is doing what it is supposed to do with the data.  But I got screwed.

>iEYEARECAAYFAkkAKB4ACgkQkDLqNwOhpPin2gCgtHuA1I2S/+Gok9TQ3BNnN7Pw
>Z+MAn2YAD/HLWriLwP0y2+q55FScRfW8
>=nwDQ

---

From: Edward Lewis <[email-masked]>
Date: Thu, 23 Oct 2008 23:10:48 +0200

At 12:25 -0400 10/23/08, Michael StJohns wrote:

>My suggestions are an attempt to provide a chain of proof from the original
>trust anchor (provided by the DNAME publisher or its parent) through to the
>final answer.

I think that's all out of bounds for DNSSEC.  DNSSEC is protecting 
the transfer of data within the DNS.

o What if you go to a signed NAPTR record, get a replacement name that
   is unsigned, then a replacement string that goes to a signed SRV which
   leads to an unsigned A record?

o What if you to to a web page that has a signed A record but are then
   redirected to a web page that has no signed address record?

DNAME, CNAME, NAPTR, and some applications the query changes from the 
start to end of the whole DNS session.  I'm now defining (becuase it 
is convenient for my side of the argument) "DNS session" to consist 
of any number of DNS iterations leading to the satisfaction of the 
application.  DNSSEC protects the iteration, not the session.

o What does DNS tell a user if an application, outside of the DNS, changes
   the name sought as a result of it's lookup process, starting from a name
   that was DNSSEC validated to a name that has no DNSSEC ancillary data?

More or less, I don't think the problem (as I understand what Mike 
wants) is solvable or is commonplace enough (or even realistic) to 
warrant something so radical as barfing the DS record.  (Heck, it's a 
hack Olafur invented, that was one of the three things I didn't like 
about it an eon ago - ask him.)

Too bad I can't make it to Bethesda tonight so we could talk this 
over at the corner of Del Ray and Norfolk.  (I.e., where there would 
be witnesses.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Mark Andrews <[email-masked]>
Date: Fri, 24 Oct 2008 09:24:27 +1100

In message <[email-masked]>, Michael StJohns writes:
> One of the problem we get with DNS is that there are two views of the data (a
> t least) - the publisher's, and the resolver's views. DNSSEC makes this more 
> complicated by the presence or absence of certain trust anchors.
> 
> As publisher, I have a signed domain, and as publisher, I publish a DNAME als
> o pointing at a signed domain.  I've done my due diligence as you suggest - I
> even own the target zone.

	Signing the zones and publishing DS / DLV records is due
	diligence.  At that point you need to trust that the resolver
	operator will do due diligence and configure all known trust
	anchors or use a DLV service.

	Yes there will be configurations that will not return SECURE
	when there is theoretically enough information to return
	SECURE.

	And the simple answer is to just ensure that there is a
	chain of trust from the root to both zones.  If you are
	unhappy about the lack of trust chains lobby your politicians
	and registry operators to get the root and infrastructure
	zones signed.

	This is not something we need to "fix" using technology.
	What we have today is complicated enough to manage without
	having to track cross zone pseudo delegations.

	Mark

---

From: Michael StJohns <[email-masked]>
Date: Fri, 24 Oct 2008 17:54:40 -0400

>        anchors or use a DLV service.

I haven't a clue how you would expect to administer this.  When was the last time you heard of someone running a zone who changed it out for a DNAME announcing this to the world? 

5011 provides a mechanism to track changes in trust anchors without having to have an out of band path to those changes.  Are you proposing that we create some sort of DNAME announcement protocol?  Or are you suggesting something else?

Let's work this further.  Say .COM is signed, but .EDU isn't.  Say I'm in a secure zone under .com - example.com.  Say the DNAME is from subzone.example.com to  otherzone.edu.  Say otherzone.edu is signed.  Say the resolver has a trust anchor for .COM.     How the heck do I as the owner of subzone.example.com figure out which resolvers to tell about the change??  

 In many (most?) organizations, the guys who run the authoritative servers and update the data in the zones are not the guys who run the local resolvers, so even in the same organization the administrators may not realize they need to do something special.  Certainly the DNAME documentation doesn't describe any operational considerations related to DNSSEC.

>        and registry operators to get the root and infrastructure

That may be the simple answer, but even simple answers are difficult. See above.

And the fact that all nodes chain to a trust anchor is not sufficient to say that there is an unbroken chain of trust from the first trust anchor to the last answer.

>        having to track cross zone pseudo delegations

*sigh*  There's complicated and there's correct.  If its complicated and wrong, its still wrong.

---

From: Edward Lewis <[email-masked]>
Date: Sat, 25 Oct 2008 00:21:07 +0200

At 17:54 -0400 10/24/08, Michael StJohns wrote:

>How the heck do I as the owner of subzone.example.com figure out which
>resolvers to tell about the change??

The answer is "you don't" and "DNSSEC never promised you could." 
Remember that the, okay, a fundamental rule of DNSSEC is that it is 
there to protect the resolver and not the authority of the data.  You 
(as an admin) don't have any tools to reach out and touch your 
audience.  Just as DNSSEC does not guarantee the answer will get 
through (no DoS prevention) it only guarantees that what is received 
can be validated (if the stars align).  DNSSEC is driven from the 
resolver and not the authority.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 27 Oct 2008 12:03:00 +0400

[Warning, most of the ideas here come from my colleeague Mohsen
Souissi but he is too busy to write now.]

On Thu, Oct 23, 2008 at 11:10:48PM +0200,
 Edward Lewis <[email-masked]> wrote 
 a message of 46 lines which said:

> o What if you go to a signed NAPTR record, get a replacement name
>   that is unsigned, then a replacement string that goes to a signed
>   SRV which leads to an unsigned A record?

The reasonable thing to do, security-wise, is to decide that the
validity of the "DNS session" is the validity of the *worse*
iteration. If all the "DNS iterations" yield Secure and one yields
Insecure, the whole session is Insecure. If some yield Secure, some
Insecure, and one yields Bogus, the net result is Bogus.

This will make things more difficult to debug, but, from a security
point of view ("the strength of the chain is the strength of the
weakest link"), it seems the only thing to do.

It will be difficult to implement because a validating resolver cannot
know what iterations are in the same session. You'll have to do it in
the application.

> o What if you to to a web page that has a signed A record but are
>   then redirected to a web page that has no signed address record?

More complicated to handle since it is not purely DNS. Is the HTTP
redirection done over TLS? :-)

---

From: Edward Lewis <[email-masked]>
Date: Mon, 27 Oct 2008 09:10:04 -0400

>Souissi but he is too busy to write now.]

He provides a good "straight man" [http://en.wikipedia.org/wiki/Comic_foil]...

>Insecure, and one yields Bogus, the net result is Bogus.

That's valid - but remember that DNSSEC does not protect the DNS 
session, just the passing of data through the system of servers.

Consider the query for "T_ANY" towards any authoritative server's 
apex (of any zone hosted).  The return includes SOA, NS, and maybe 
other record sets.  DNSSEC can be used to set-wise individually 
validate, but not report a status for the entire answer.  (As in, 
there's just one RCODE field, no way to say "this is good, that bad, 
that good.)

We were frustrated by that inability when writing the code way back.

>redirection done over TLS? :-)

And that's also directly working into the point I was making, the 
security of the session is dependent on all sorts of things, in this 
case external to DNSSEC.  DNSSEC can't (as in lacks the bit fields 
to) "protect" the chain from what the consuming user types into the 
browser and where the HTTP protocol ultimately sends the user.

Yes, a bit far fetched and out of bounds for a DNS argument.  I 
mentioned this example to show why we really can't go even "half-way" 
to securing a CNAME/DNAME/query re-direction/write "path" through the 
DNS, just the data as it is presented.  You have to also trust the 
software correctly implements the protocol, not just sign the data.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar