Subject: [DNSOP] Comments on DS Publication draft

From: Rickard Bellgrim <[email-masked]>
Date: Wed, 10 Nov 2010 16:53:01 +0100

Hi

I have some comments on the document draft-barwood-dnsop-ds-publish-01:

1. Introduction (3rd paragraph)
It is not always the case that the child is the one defining the DS RRset. Some parents wants (for some reason) to create the DS RRset based on their own policy (choice of hash) and based on what DNSKEY RR the child send in.

1. Introduction (5th paragraph)
The CDS RR would not be used for automation of rollovers but rather the automated key exchange from child to parent. (Key exchange is one step in the rollover process)

3. Resource Record Format (3rd paragraph)
I do not think you should limit what key type can be used for creating the signature for this RRset. As long as the parent can verify it using the previous DS RRset via the child's DNSKEY RRset. In fact, forcing the use of KSK for this RRset's signature will break some assumptions in the key timing draft.

3. Usage (1st paragraph)
How do you know what name server to send the NOTIFY to? SOA MNAME? Configurable option? Service discovery? etc

3. Usage (2nd paragraph)
I think you should change the SHOULD to a MUST: "The parent zone MUST attempt to authenticate"

3. Usage (2nd paragraph)
"If the authentication succeeds or yields Insecure, extra security checks are not normally necessary"
This statement makes it possible to do a DoS on this zone. An attacker could send a DS to the parent in the name of the unsigned child. This means that this draft should only be used after that the first initial key exchange has been done, where the parent can actually use DNSSEC to verify the changes.

3. Usage (3rd paragraph)
Nothing prevents you from having a DS RR pointing to a zone signing key. Thus no need to do this check.

3. Usage (7th paragraph)
And since I am trying to remove the constraint on only using a KSK to create a signature for this RRset, you should also change:
"where a key signing key has been compromised"
to
"where a key has been compromised"

// Rickard

---

From: "George Barwood" <[email-masked]>
Date: Thu, 11 Nov 2010 22:15:20 -0000

----- Original Message ----- 
From: "Rickard Bellgrim" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, November 10, 2010 3:53 PM
Subject: [DNSOP] Comments on DS Publication draft

> It is not always the case that the child is the one defining the DS RRset. Some parents wants (for some reason) to create the DS RRset based on their own policy (choice of hash) and based on what D…
 
I'll take your word for this, but this practice seems a "very bad idea" to me.
I cannot see any justification, it just creates future inter-operability barriers
and obstacles for the introduction of new hash algorithms in future.
It seems incompatible with the CDS concept ( or at least implies some complication ).
As the draft states, the ability to publish an arbitrary DS record in the parent may be
valuable in future, so it seems wise to retain that option.

> The CDS RR would not be used for automation of rollovers but rather the automated key exchange from child to parent. (Key exchange is one step in the rollover process)

Well yes, it enables automation (and this is the main motivation for the draft), it clearly is not the complete process.
I will amend the language in the next version.
 
> I do not think you should limit what key type can be used for creating the signature for this RRset. As long as the parent can verify it using the previous DS RRset via the child's DNSKEY RRset. In…

Can you be more explicit about how it conflicts with the key timing draft?
The logic for restricting the key type is that where a ZSK private key is kept online,
a breach of security would not allow the parent DS to be disrupted ( and such disruption
could be difficult to reverse ). This seems a solid advantage, and I don't see any disadvantage.
 
> How do you know what name server to send the NOTIFY to? SOA MNAME? Configurable option? Service discovery? etc

The draft says "a name server for the parent zone". Is that not clear? It means any one of the servers defined by
the parent NS RRset. I don't see any need for a more complex mechanism, but suggest a more complex
mechanism if you think that is an improvement.
 
> I think you should change the SHOULD to a MUST: "The parent zone MUST attempt to authenticate"

Ok.
 
> This statement makes it possible to do a DoS on this zone. An attacker could send a DS to the parent in the name of the unsigned child. This means that this draft should only be used after that the…

I suggest it's up to the policy of the parent zone ( and policy is not best dealt with here). 
An insecure zone is clearly insecure until it is signed. This possibility would encourage
owners of child zones to sign the zone, as once signed this vulnerability disappears. 
In practice most parent zones would probably require some manual step in addition
( using the same access as is currently used to maintain the NS RRset in the parent ).
But the alternate policy has an incentive effect, so should be permitted I think.

> "where a key has been compromised"

Thanks for your comments. Would you support the adoption of this draft by the WG?

- George

> // Rickard
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Thu, 11 Nov 2010 15:32:24 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> George Barwood
> Sent: Thursday, November 11, 2010 4:15 PM
> To: Rickard Bellgrim; [email-masked]
> Subject: Re: [DNSOP] Comments on DS Publication draft
> 
> 
> > It is not always the case that the child is the one defining the DS
> RRset. Some parents wants (for some reason) to create the DS RRset
based
> on their own policy (choice of hash) and based on what DNSKEY RR the
child
> send in.
> 
> I'll take your word for this, but this practice seems a "very bad
idea" to
> me.
.GOV currently creates their own DS from the DNSKEY they "customer"
uploads to the web gui. There is no way to create the DS yourself. I
agree that this is bad practice but I think we need to take this into
account.

/S

---

From: Rickard Bellgrim <[email-masked]>
Date: Fri, 12 Nov 2010 03:32:29 +0100

> valuable in future, so it seems wise to retain that option.

Yes, some TLD do this. The EPP protocol allows you to send the DNSKEY instead of the DS RR. Other TLD:s also enforce you to have the DNSKEY published before you can add the DS to the parent. But this is more a discussion for RFC4641bis, where my own thought is that the TLD should accept any (limited numbers of) DS from the child.

But all of this does not make this draft useless. It is just that the zone owner needs to know what the parent expect.

> could be difficult to reverse ). This seems a solid advantage, and I don't see any disadvantage.

The definition is that the KSK creates signatures for DNSKEY RRset. This creates some assumptions for the various KSK mechanisms. Because you know that the signatures created with this key are bundled only with the DNSKEY RRset. You thus know when signatures are removed from caches etc. And that you know that a DNSKEY can be removed at once without postpublishing (or made active with no prepublishing), since there are no other RRset that needs to be validated with this key. DNSKEY RRset + RRSIG are always cached together.

Yes, you are right. You are then relying on the security of the ZSK to update the DS.

> mechanism if you think that is an improvement.

Yes, that part is clear. But then you (the TLD) have to forward the update request from the secondary back to the hidden master / database. And the secondaries can also be outsourced to other parties, separate from the one owning the authoritative data. You probably want to send the update somewhere close to the source of the authoritative data.

> But the alternate policy has an incentive effect, so should be permitted I think.

No, I would not like to implement this. This would mean that an attacker could inject fake DS RR to all of our unsigned child zones. There is no authentication mechanisms if you have not done the first initial key exchange using channels like EPP, where you upload the first DS.

This is a Denial of Service since the child zone then get marked as bogus. DS in the parent, but the child has no signatures.

1. Upload the first DS manually using EPP or similar.
2. Enable the mechanism in this draft.

> Thanks for your comments. Would you support the adoption of this draft by the WG?

You're welcome. My comments now was just now on the design. I have to do some more thinking and compare this with other solutions.

// Rickard

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Thu, 11 Nov 2010 19:49:24 -0700

Richard and George,

Of
> Rickard Bellgrim
> Sent: Thursday, November 11, 2010 8:32 PM
> To: George Barwood
> Cc: [email-masked]
based
child
> > I'll take your word for this, but this practice seems a "very bad
idea"
> to me.
> > I cannot see any justification, it just creates future
inter-operability
> barriers
> > It seems incompatible with the CDS concept ( or at least implies
some
> complication ).
> > As the draft states, the ability to publish an arbitrary DS record
in
> the parent may be
> Yes, some TLD do this. The EPP protocol allows you to send the DNSKEY
> instead of the DS RR. Other TLD:s also enforce you to have the DNSKEY
> published before you can add the DS to the parent. But this is more a
> discussion for RFC4641bis, where my own thought is that the TLD should
> accept any (limited numbers of) DS from the child.
> 
> But all of this does not make this draft useless. It is just that the
zone
> owner needs to know what the parent expect.

Or we could just publish a DNSKEY with another set of flags and leave it
up to the parent to create the DS. That would be a nicer solution and we
wouldn't have this problem. Additionally, I think the section justifying
the new RR is weak. Especially, "delaying the time at which an attacker
can start cryptanalysis". We are talking about hours or days here not
decades, right?

/S

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 15 Nov 2010 11:52:24 -0500

On 11/11/2010 5:32 PM, Stephan Lagerholm wrote:
>> From: "Rickard Bellgrim"<[email-masked]>
>> To:<[email-masked]>

Maybe we need a paragraph in rfc4641bis saying why this is a bad idea.
In my mind this boils down to the arguments as if
	 "parent knows best" vs "child knows best".

Having observed .gov in action I think we need to make strong case
for "parent should not mess up child".

	Olafur