Subject: [mif] DNSSEC trust anchors as a side channel for preferring an interface

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Mar 2011 08:08:20 -0400

Hi,

Something that came up in the discussion today in the meeting was the
way that using trust anchors as a way of establishing trust in an
interface for answers for part of the name space might work.

I think it was Ted who was suggesting that there might be a problem
with having the same key signing the public-Internet-horizon answer
and the intranet-horizon answer.  The answer is, "Don't do that."

If we want to tell people that using special-purpose trust anchors as
the foundation link in a validation chain, and that such a chain is
the message that tells you, "I'm the special-purpose 'internal' DNS
server," then the chain for such a message has to be distinct from the
chain you'd get from the public Internet root.  This does potentially
mean more DNSKEYs in the DNSKEY RRset.  That's the cost of using this
trick.

If the answer is, "Ooh, people won't do this.  They want one and only
one key," then I say DNSSEC is the wrong hammer for that nut and bolt.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Mar 2011 15:53:37 +0000

What happened here, I think, is that I posited a problem--essentially the problem you mentioned in your previous message, which is that the DNS server selection option can be used to provide DNS server IP addresses for which will then provide wrong answers for certain domains.  I offered to write some text for Teemu explaining how to use DNSSEC to mitigate this problem.  I never wrote the text.  Teemu wrote his own text, based on his understanding of what I'd asked for, which was slightly different than what I intended (understanding that I had never clearly thought the problem through to its conclusion--I offered to write the text intending to think it through when I wrote it).

The point of this exercise (hopefully Teemu will correct me if I am wrong on this) is to prevent the type of domain hijacking I described above.   It's not to choose a different answer based on what trust anchor was used to sign the zone.   I think you *can* sign an internal and external zone using the same key, and generally have that work, as long as you don't cache answers from both zones and attempt to validate some answer by combining answers from the two versions of the zone.   If that's not the case, it's potentially a problem for this draft.

Be that as it may, the main point of this exercise was to provide a way for securely detecting an attempt to spoof DNS responses for a signed zone--that is, a way to prevent this option from serving as a mechanism for bypassing DNSSEC.   In order for that to happen, both copies of the zone have to validate to the root; it is the fact that the spoofed zone will fail to validate to the root that allows us to discard it.   The idea of differentiating between different zones on the basis of the trust anchor used to validate them was not what I intended, and I don't think Teemu had it in mind as a requirement either, although I may be mistaken about that--I think it's just a mistranslation of a muddy explanation I'd given to him back around the time of the Beijing meeting.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Mar 2011 12:59:05 -0400

On Mon, Mar 28, 2011 at 03:53:37PM +0000, Ted Lemon wrote:
> 
> Be that as it may, the main point of this exercise was to provide a
> way for securely detecting an attempt to spoof DNS responses for a
> signed zone--that is, a way to prevent this option from serving as a
> mechanism for bypassing DNSSEC.  In order for that to happen, both
> copies of the zone have to validate to the root; it is the fact that
> the spoofed zone will fail to validate to the root that allows us to
> discard it.  The idea of differentiating between different zones on

No.  You can discard it because it fails validation to some trust
anchor you have.  You could have lots of them.  What I was suggesting
is that we could use that trick to tell us which interface to prefer
for a zone, in case more than one interface told us it was supported.

What wasn't clear to me after today is whether we think that's
something we ever need to care about.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Mar 2011 17:56:50 +0000

> for a zone, in case more than one interface told us it was supported.

Sorry to be dense, but to which trick are you referring?

In general I don't think we really want to require people to configure trust anchors, although in principle I suppose that's a valid way to do things, presuming that the support were there in the DNSSEC implementation, which I think you said is not the case.

---

From: <[email-masked]>
Date: Mon, 28 Mar 2011 21:38:14 +0000

In the text I actually tried to cover both of these cases: 
- protect against domain hijacking
- in case of different but validated answers choose the more preferred one

If we want to scope down the solution a bit, we might want to focus only on protecting against hijacking and not cover selection between multiple validated responses?

	Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Andrew Sullivan
> Sent: 28. maaliskuuta 2011 18:59
> To: Ted Lemon
> Cc: [email-masked]
> Subject: Re: [mif] DNSSEC trust anchors as a side channel for
> preferring an interface
> 
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: Ted Lemon <[email-masked]>
Date: Tue, 29 Mar 2011 06:32:51 +0000

> If we want to scope down the solution a bit, we might want to focus only on protecting against hijacking and not cover selection between multiple validated responses?

That seems okay to me. It should be possible to choose between two different validated responses on the basis of the server preference option without resorting to checking for differences in keys.  Although I must admit that this still requires an extended API.