Re: [DNSOP] Comments on DS Publication draft

----- Original Message ----- 
From: "Rickard Bellgrim" <rickard.bellgrim@iis.se>
To: <dnsop@ietf.org>
Sent: Wednesday, November 10, 2010 3:53 PM
Subject: [DNSOP] Comments on DS Publication draft

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

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.

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

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.

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

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.

> 3. Usage (1st paragraph)
> 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.

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

Ok.

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

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.

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

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

- George

> // Rickard
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop