Subject: [DNSOP] Proposed changes to RFC 4641: differentiation between trust anchors and keys with parent zones

From: Paul Hoffman <[email-masked]>
Date: Sun, 28 Sep 2008 21:14:38 -0700

In the last paragraph of 3.1.1, change:
    These
    can include the registry of the parent zone or administrators of
    verifying resolvers that have the particular key configured as secure
    entry points.
to:
    If there is a parent zone, these
    can include the registry of the parent zone or administrators of
    verifying resolvers that have the particular key configured as secure
    entry points. If this is a trust anchor, everyone relying on the trust
    anchor needs to roll over to the new key, which is a very big deal.

Remove all of 3.1.2. Longer keys are not useful because the crypto
guidance is that everyone should use keys that no one can break. Also,
it is impossible to judge which zones are more or less valuable to an
attacker. An attack can only be used if the compromise is unnoticed
and the attacker can act as an MITM in an unnoticed way. If .com is
compromised and the attacker forges answers for somebank.com and sends
them out as an MITM, when the attack is discovered it will be simple
to prove that .com has been compromised and the KSK will be rolled.
Defining a long-term successful attack is difficult for keys at any
level.

Remove the first phrase of the fourth paragraph of 3.3. At the end of
the paragraph, add:
    Note that if a trust anchor replacement is done incorrectly, the
    entire zone that the trust anchor covers will become bogus until
    the trust anchor is corrected.

Here's the biggie. Separate all of section 4 into two distinct
sections: zones publishing trust anchors, and zones publishing DS
records to a parent. Make each heading clear which one is being
discussed.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 29 Sep 2008 08:13:41 -0700

>>>>> On Sun, 28 Sep 2008 21:14:38 -0700, Paul Hoffman <[email-masked]>
said:

Again, I completely agree with the goal of trying to remove some of the
key-rollover requirements because of key-length and usage issues that
are likely bogus.  However, I think your proposed edits fail to take
into account other issues.

PH> If this is a trust anchor, everyone relying on the trust anchor
PH> needs to roll over to the new key, which is a very big deal.

[... and later ...]

PH> Here's the biggie. Separate all of section 4 into two distinct
PH> sections: zones publishing trust anchors, and zones publishing DS
PH> records to a parent. Make each heading clear which one is being
PH> discussed.

Life and documentation may have been a lot easier if the technical
specifications said "If a parent zone has a properly signed DS record
for a zone, the DNSKEY for that zone MUST NOT be used as a trust
anchor".  But it doesn't.  Any key may be used as a trust anchor and
it's impossible for a zone operator to tell whether their DNSKEY's in
their zone are used for trust anchors or not.  There are plenty of
previously discussed reasons for using a list of trust anchors that
include zones with a parent-child DS in place.  I won't get into the
politics or even state which side I'm on.  That's not the point; the
point is that the reality of the situation is that you can't ensure your
key isn't being used as a trust anchor.  Thus, if you care about people
using your data, all keys must be rolled as if they're trust anchors.
PH> An attack can only be used if the compromise is unnoticed and the
PH> attacker can act as an MITM in an unnoticed way.

Please don't use MITM terminology when it comes to DNS...  DNS is much
more vulnerable to man-not-quite-in-the-middle attacks than other
protocols due to poisoning attacks and spoofing issues.  (I don't think
you put MITM wording in your proposal text anywhere, however, and are
only using it in your arguments).

PH> If .com is compromised and the attacker forges answers for
PH> somebank.com and sends them out as an MITM, when the attack is
PH> discovered it will be simple to prove that .com has been compromised
PH> and the KSK will be rolled.

I doubt it will be simple to prove.  Proof requires records, which are
usually the first thing an attacker attempts to delete when compromising
something (robust systems will protect against this issue of course).
Either way, proving to an external entity that a key was compromised vs
an intentional malicious action by the key owner is rarely possible.

PH> Defining a long-term successful attack is difficult for keys at any
PH> level.

I suspect that a long term targeted attack on MX records for email
sniffing purposes isn't as hard to pull off as you'd think.  The type of
attack makes all the difference in the world as far as how easy it is to
detect.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 29 Sep 2008 08:13:41 -0700

said:

[... and later ...]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 29 Sep 2008 12:36:40 -0700

At 8:13 AM -0700 9/29/08, Wes Hardaker wrote:
>Any key may be used as a trust anchor and
>their zone are used for trust anchors or not.

Fully agree.

>There are plenty of
>key isn't being used as a trust anchor.

Yep.

>Thus, if you care about people

A better way to say this is "if you care that people might use your 
key as a trust anchor, it is relatively easy to help them by acting 
in some ways like a trust anchor".

The planning for being a trust anchor is quite different than the 
actions you need to take if you have a parent and you just want to 
sign your zone and maybe later care about rollover. Having 4641bis 
say "you must be able to act like a trust anchor whether or not you 
want to" is bad advice and will deter the vast majority of zones that 
should be signed from wanting to be signed.

One way to deal with this is to describe the ways that some users 
might want to use your parent zone to get your initial DS key and 
then use your key as a trust anchor. There are reaFrom [email-masked]  Mon Sep 29 12:36:35 2008
Date: Mon, 29 Sep 2008 12:36:40 -0700
To: Wes Hardaker <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [DNSOP] Proposed changes to RFC 4641: differentiation between
 trust anchors and keys with parent zones
Sender: [email-masked]

At 8:13 AM -0700 9/29/08, Wes Hardaker wrote:
>Any key may be used as a trust anchor and
>their zone are used for trust anchors or not.

Fully agree.

>There are plenty of
>key isn't being used as a trust anchor.

Yep.

>Thus, if you care about people

A better way to say this is "if you care that people might use your 
key as a trust anchor, it is relatively easy to help them by acting 
in some ways like a trust anchor".

The planning for being a trust anchor is quite different than the 
actions you need to take if you have a parent and you just want to 
sign your zone and maybe later care about rollover. Having 4641bis 
say "you must be able to act like a trust anchor whether or not you 
want to" is bad advice and will deter the vast majority of zones that 
should be signed from wanting to be signed.

One way to deal with this is to describe the ways that some users 
might want to use your parent zone to get your initial DS key and 
then use your key as a trust anchor. There are reasosons for this that 
are not covered in any RFC I have seen, and a reader of 4641bis might 
get value out of thinking about this.

After that, we could talk about the few steps needed to act like a 
trust anchor by following RFC 5011. There are two aspect here: 
following the timing, and updating old keys with the REVOKE flag. 
This does *not* mean publishing your key outside the DNS as current 
TLDs need to; saying that every zone should do that will scare them 
away.

>only using it in your arguments).

Fully agree. DNS's use of UDP makes the middle very un-middle-like.

>an intentional malicious action by the key owner is rarely possible.

Agree that this would not be simple to prove. If it is a real 
concern, someone could put out a bunch of dispersed collectors that 
log all responses in the hope that the attacker sends one of them the 
spoofed reply. That's very hit-and-miss, of course.

>attack makes all the difference in the world as far as how easy it is to

Exactly right.

--Paul Hoffman, Director
--VPN Consortium

ns for this that 
are not covered in any RFC I have seen, and a reader of 4641bis might 
get value out of thinking about this.

After that, we could talk about the few steps needed to act like a 
trust anchor by following RFC 5011. There are two aspect here: 
following the timing, and updating old keys with the REVOKE flag. 
This does *not* mean publishing your key outside the DNS as current 
TLDs need to; saying that every zone should do that will scare them 
away.

>only using it in your arguments).

Fully agree. DNS's use of UDP makes the middle very un-middle-like.

>an intentional malicious action by the key owner is rarely possible.

Agree that this would not be simple to prove. If it is a real 
concern, someone could put out a bunch of dispersed collectors that 
log all responses in the hope that the attacker sends one of them the 
spoofed reply. That's very hit-and-miss, of course.

>attack makes all the difference in the world as far as how easy it is to

Exactly right.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Mon, 29 Sep 2008 22:03:04 -0400 (EDT)

On Sun, 28 Sep 2008, Paul Hoffman wrote:

> An attack can only be used if the compromise is unnoticed
> and the attacker can act as an MITM in an unnoticed way.

Not at all. Even when noticed, there is still the time before the
majority of the world has fixed the compromised use for which there
are still victims to use the attack against.

24 hours of owning .com can be pretty profitable.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 29 Sep 2008 22:03:04 -0400 (EDT)

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 29 Sep 2008 19:39:28 -0700

>are still victims to use the attack against.

Fully agree, and I was to glib there. I should have said "...can only 
be used long term if..."

>24 hours of owning .com can be pretty profitable.

True, but a key compromise of the .com KSK or current ZSK is not 
quite the same as "owning". But this is not relevant, since this is 
not text I was proposing to put in the document, just an explanation 
why I removed something that was better discussed elsewhere.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 29 Sep 2008 19:39:28 -0700

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked]
Date: Mon, 29 Sep 2008 11:58:14 +0000

>    anchor needs to roll over to the new key, which is a very big deal.

	when is a SEP not a TA?

> guidance is that everyone should use keys that no one can break. Also,

	crypto guidance from whom?  longer keys are useful for several
	reasons.

> it is impossible to judge which zones are more or less valuable to an

	value is in the eyes of the zoen admin, not a random hacker.

> Remove the first phrase of the fourth paragraph of 3.3. At tFrom [email-masked]  Mon Sep 29 22:57:12 2008
Date: Mon, 29 Sep 2008 11:58:14 +0000
From: [email-masked]
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [DNSOP] Proposed changes to RFC 4641: differentiation between
	trust anchors and keys with parent zones
Sender: [email-masked]

>    anchor needs to roll over to the new key, which is a very big deal.

	when is a SEP not a TA?

> guidance is that everyone should use keys that no one can break. Also,

	crypto guidance from whom?  longer keys are useful for several
	reasons.

> it is impossible to judge which zones are more or less valuable to an

	value is in the eyes of the zoen admin, not a random hacker.

> Remove the first phrase of the fourth paragraph of 3.3. Athe end of
> the paragraph, add:

	manipulation of the TA/SEP nonces fundamentally changes the validators view of trust.
	one presumes that your assuming a single trust heirarchy and wiggling  one piece to give
	a parallax view creates "bogus" data -from the perspective of one view of a trust heirarchy-.

	alternate trust heirarchies will emerge.

 the end of
>    the trust anchor is corrected.

	manipulation of the TA/SEP nonces fundamentally changes the validators view of trust.
	one presumes that your assuming a single trust heirarchy and wiggling  one piece to give
	a parallax view creates "bogus" data -from the perspective of one view of a trust heirarchy-.

	alternate trust heirarchies will emerge.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 30 Sep 2008 08:05:04 -0700

At 11:58 AM +0000 9/29/08, [email-masked] wrote:
>	crypto guidance from whom?

That guidance, as it were, is in RFC 4641.

>longer keys are useful for several
>	reasons.

Please explain. Using keys longer than the actual security needs 
waste CPU cycles both for the signing zone and the recursive DNS, and 
also waste bandwidth.

>	value is in the eyes of the zoen admin, not a random hacker.

Of course. If you have proposed text to help a zoen admin put a value 
on their zone that can be translated into signing key lengths, please 
post it.

>	alternate trust heirarchies will emerge.

Fully agree; they already have. How does that affect the change that 
I proposed?

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 30 Sep 2008 08:05:04 -0700

--Paul Hoffman, Director
--VPN Consortium

---

From: "TS Glassey" <[email-masked]>
Date: Tue, 30 Sep 2008 08:38:00 -0700

Paul is not looking at the operations of DNSSEC as something that WILL by 
its very process need to be Court Admissible Evidence and so that is not 
being considered here.

Todd Glassey

----- Original Message ----- 
From: "Paul Hoffman" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, September 30, 2008 8:05 AM
Subject: Re: [DNSOP] Proposed changes to RFC 4641: differentiation between 

> waste CPU cycles both for theFrom [email-masked]  Tue Sep 30 08:43:33 2008
From: "TS Glassey" <[email-masked]>
To: <[email-masked]>,
	"Paul Hoffman" <[email-masked]>
Date: Tue, 30 Sep 2008 08:38:00 -0700
Subject: Re: [DNSOP] Proposed changes to RFC 4641: differentiation between
	trust anchors and keys with parent zones
Sender: [email-masked]

Paul is not looking at the operations of DNSSEC as something that WILL by 
its very process need to be Court Admissible Evidence and so that is not 
being considered here.

Todd Glassey

----- Original Message ----- 
From: "Paul Hoffman" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, September 30, 2008 8:05 AM
Subject: Re: [DNSOP] Proposed changes to RFC 4641: differentiation between 

> waste CPU cycles both for t signing zone and the recursive DNS, and
> also waste bandwidth.
>

--------------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.173 / Virus Database: 270.7.5/1700 - Release Date: 9/30/2008 
11:03 AM

he signing zone and the recursive DNS, and
> Fully agree; they already have. How does that affect the change that

--------------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.173 / Virus Database: 270.7.5/1700 - Release Date: 9/30/2008 
11:03 AM

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 30 Sep 2008 09:12:03 -0700

At 3:42 PM +0000 9/30/08, [email-masked] wrote:
>	perhaps I was not clear.  I expect that keys
>	of different lengths adn validity periods will be the
>	norm.  I cna not conceive of a workable model that shares
>	a single key length/validity period  for any key, anywhere
>	in the namespace.

Ah. We agree, then. Nothing that I put in my proposed changes 
mandated any particular length or validity period, I believe.

>	can you seriously assert that the keys used to sign a TLD that
>	gets perhaps a couple dozen changes per year  should have the
>	same characteristics as the keys used to sign a zone
>	with 200 updates per minute or a zone recording DHCP leases that
>	last no more than 15 minutes and do it with a straight face?

I never said "should have". And, yes, I fully From [email-masked]  Tue Sep 30 09:11:57 2008
Date: Tue, 30 Sep 2008 09:12:03 -0700
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [DNSOP] Proposed changes to RFC 4641: differentiation between
 trust anchors and keys with parent zones
Sender: [email-masked]

At 3:42 PM +0000 9/30/08, [email-masked] wrote:
>	perhaps I was not clear.  I expect that keys
>	of different lengths adn validity periods will be the
>	norm.  I cna not conceive of a workable model that shares
>	a single key length/validity period  for any key, anywhere
>	in the namespace.

Ah. We agree, then. Nothing that I put in my proposed changes 
mandated any particular length or validity period, I believe.

>	can you seriously assert that the keys used to sign a TLD that
>	gets perhaps a couple dozen changes per year  should have the
>	same characteristics as the keys used to sign a zone
>	with 200 updates per minute or a zone recording DHCP leases that
>	last no more than 15 minutes and do it with a straight face?

I never said "should have". And, yes, I fully bebelieve "could have".

>	i didn't think so.

That's fine, but it would be helpful for you to back it up with an 
explanation that could lead to text changes. Given that you have 
numbers above, please show how the different key sizes that you are 
recommending affect the zone signing.

>	augmenting your text - "... will ebcome bogus WITHIN A GIVEN 
>TRUST HEIRARCHY."
>	and dropping "until the trust anchor is corrected" ...  the 
>trust anchor
>	is perfectly fine for a divergent trust heirarchy and should 
>not be "corrected".

Got it. That looks good to me.

--Paul Hoffman, Director
--VPN Consortium

lieve "could have".

>	i didn't think so.

That's fine, but it would be helpful for you to back it up with an 
explanation that could lead to text changes. Given that you have 
numbers above, please show how the different key sizes that you are 
recommending affect the zone signing.

>	augmenting your text - "... will ebcome bogus WITHIN A GIVEN 
>TRUST HEIRARCHY."
>	and dropping "until the trust anchor is corrected" ...  the 
>trust anchor
>	is perfectly fine for a divergent trust heirarchy and should 
>not be "corrected".

Got it. That looks good to me.

--Paul Hoffman, Director
--VPN Consortium