Subject: [DNSOP] feedback/feelings around : draft-barwood-dnsop-ds-publish-02.txt ?

From: "Marc Lampo" <[email-masked]>
Date: Mon, 11 Jul 2011 11:51:34 +0200 (CEST)

Dear all,

http://tools.ietf.org/id/draft-barwood-dnsop-ds-publish-02.txt

There does not seem to be a lot of feedback on this draft ?
 (some comments on version 01 only)

Yet, couldn’t this lead to better acceptance of DNSSEC deployment ?

Personally I had two questions/remarks when I (only) just read this version 
:
1) First paragraph of “Usage” :
“Child zone MAY send a NOTIFY message”
→ if this is a regular DNS Notiry message to make a slave check SOA on a 
slave,
     secure configuration of the master would surely block notify messages !
     (the “parent” of a domain is not guaranteed to be slave for it !)
2) “Usage” paragraph 3 : parent should check SEP flag is set.
This would mean only DS’s corresponding to KSK’s can be in the parent zone ?
Isn’t this contradictory with other statements to use only one type of 
DNSKEY ?
(not that I am in favour of that – I already contributed I am not,
 but I accept that some may prefer only one type)

Kind regards,

Marc Lampo
Security Officer

    EURid
    Woluwelaan 150
    1831 Diegem - Belgium
    TEL.: +32 (0) 2 401 3030
    MOB.:+32 (0)476 984 391
    [email-masked]
    http://www.eurid.eu

Want a .eu web address in your own language? Find out how so you don’t miss 
out!

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 21 Jul 2011 13:39:19 +0200

>  (some comments on version 01 only)

I have read the draft, and I have given it some thought.
Though I advocate a child-parent signalling method for key roll-overs, I
think this is not the correct way forward, and I'll explain why.

As a registry for .nl we have decided not to accept DS records from
childs, but DNSKEY instead, and calculate the DS ourselves.
The reason for this is multiple, but the major considerations are that
since the DS is on the parent side of the zone cut, we want to be able
to control the supported hashing algorithm for the DS in our zone, and
be able to change to a new algorithm without child interaction.

The major reason however is that when supporting a secure DNSSEC
dns-operator change, the registry will act as a relay for the DNSKEY
from the losing dns-operator to the new one, so in this process we need
to request the DNSKEY anyway. We don't want to request the DS and only
in the dns-operator change case request the DNSKEY as well or instead.

So since we don't accept DS, we will not support the CDS signalling.

What we think is a way forward is a way for the child to signal that a
new DNSKEY has appeared in the child zone that needs a DS at the parent,
or a way to signal a DNSKEY set that should have a corresponding DS at
the parent.
Some thoughts:
The SEP bit could be used for this but then not all keys with the SEP
bit may need a DS at the parent.
Perhaps we need another bit for this ?
I realise the SEP bit does not have this meaning right now, but I see no
hindrance in changing that definition.
A NOTIFY from child to parent may then be sufficient for the parent to
determine which keys need a DS.
But how does the child identify which parent server to send the NOTIFY to ?
And how does the receiving server at the parent know what to do with the
NOTIFY ?
And does a child always want to publish a DNSKEY in the zone before a DS
should be present at the parent, or should it be able to request a DS
for a DNSKEY before the DNSKEY is present in the zone ?
In the dns-operator change case, the DNSKEY's with this bit set should
therefore also be present in both zones, so not only both ZSK's (in a
KSK/ZSK case). This may change 4641bis again...

hope to have discussions next week

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]
http://www.sidn.nl/

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Thu, 21 Jul 2011 06:15:55 -0600

> be able to change to a new algorithm without child interaction.
Agree, this draft is not covering such scenario. And .NL is not alone doing
this. For example, .GOV is also asking for DNSKEYs instead of DS.

> Perhaps we need another bit for this ?
I suggested to use another flag for the DNSKEY a few months ago here. The
reaction from the list was that it was too complicated because the key-id
would change during the lifetime of the DNSKEY. 

> I realise the SEP bit does not have this meaning right now, but I see
> no hindrance in changing that definition.
Doesn't work. There are scenarios when you want to have the DS record
published prior to publish the DNSKEY. For example, algorithm rollovers or
double DS rollover. A new record or a new flag to the DNSKEY is required.

> And how does the receiving server at the parent know what to do with
> the NOTIFY ?
> And does a child always want to publish a DNSKEY in the zone before a
> DS should be present at the parent, or should it be able to request a DS
I Agree that the draft is missing the whole signaling piece. But it is still
a step in the right direction to try to define how the RR should look like.
The definition of the signaling can actually be defined later. 

/Stephan

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 21 Jul 2011 14:35:31 +0200

> would change during the lifetime of the DNSKEY. 

Why would you look at the key-id ?
If as a parent I get a notify, I (securely) look up the DNSKEY set,
select the keys with a SEP bit and hash them to DS. What does the key-id
do in that ?
If the key-id changes during the DNSKEY lifetime, doesn't it mean the DS
at the parent should change too ?
Or do you mean there's a point in time you set the flag, and that causes
the key-id to change ? Yes, sure. But then I see that as a key change,
and you have to signal the parent anyway.

> double DS rollover. A new record or a new flag to the DNSKEY is required.

I wonder if this is a practice that needs to be reconsidered.
I can imagine you don't sign with a new key yet, but can publishing it
in the zone do harm ? Even if it's a bogus key ?
And perhaps the many roll-over scenario's we have now can be brought
back to just the ones that work in such an automated fashion.

> The definition of the signaling can actually be defined later. 

Agree, that is a next step.

- -- 
Antoin Verschuren

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Thu, 21 Jul 2011 07:47:31 -0600

> Why would you look at the key-id ?
I wouldn't, but the feedback was that we shouldn't mess with the flag field
of the DNSKEY, RFC5011 did that and it created a lot of confusion for
operators because the key-id changes.

> select the keys with a SEP bit and hash them to DS. What does the key-
> id do in that ?
Nothing, but the SEP = DS doesn't work. Some zones (.NU) doesn't even have
the SEP bit.

> If the key-id changes during the DNSKEY lifetime, doesn't it mean the
> DS at the parent should change too ?
> Or do you mean there's a point in time you set the flag, and that
> causes the key-id to change ? Yes, sure. But then I see that as a key
change,
> and you have to signal the parent anyway.
The idea was to have an embryonic flag. For example, if the embryonic flag
was in position 10 in the flag field (512):
The child operator would publish a key with flag 769 (257 + 512) signaling
the intention to soon add a DNSKEY with flag field 257.
The parent would pick up the DNSKEY and create a DS but without including
the embryonic flag in the DS calculation.
The after the child sees the DS at the parent, it would remove the embryonic
flag from the DNSKEY.

During the lifetime of the key it would have different flag fields and
different key-ids.
769 -> 257 -> 385 (if RFC5011 rollovers are used, the revoked bit could
perhaps also be extended mean that the DS should be removed from the parent)

/S

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 21 Jul 2011 10:16:31 -0400

On 21/07/2011 7:39 AM, Antoin Verschuren wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

This is a non arguments, even if the child list CDS with the 
identification of the DNSKEY's that it wants represented in the DS set,
if you can look up CDS then you can follow that with a DNSKEY query and 
pull out the appropriate keys.

The second argument as you want to control the hash algorithms, I 
understand that but at the same time think that is not reasonable unless 
you handle corner cases, like if embassy-russia.nl wants digest 3 will 
you support that?

> in the dns-operator change case request the DNSKEY as well or instead.
See above you ask for it after asking for CDS.

> So since we don't accept DS, we will not support the CDS signalling.

Sounds like you want CKEY-to-DS record i.e. record that has the keys 
that the child wants to to chash?

> or a way to signal a DNSKEY set that should have a corresponding DS at

This does not work in all cases, unless the child can control when/if 
the parent checks. (think algorithm introduction/retirement)

> hindrance in changing that definition.

A new bit would be better, but you need to think about the semantics.
IMHO CKEY-to-DS  is what you want.

> determine which keys need a DS.

The tricky question is: How does a child to tell the parent that keys 
for alg X are to be removed from DS ?
As the DS is the first place the delete takes place, then you remove the 
DNSKEY record, followed by purging the signatures.

> But how does the child identify which parent server to send the NOTIFY to ?

This is a good open question, in particular when you have the RRR model 
and the middle R demands to be in the middle of all transactions.

> And how does the receiving server at the parent know what to do with the

(new protocol)

> for a DNSKEY before the DNSKEY is present in the zone ?

This is the crux of the matter, for the reason that what is in DS does 
not have to mirror what is in DNSKEY a new type is IMHO the way to go.
A further advantage of a new type is that way the child can explicitly 
opt-in to automatic rollover of DS records. (and possibly of NS as well)

> hope to have discussions next week

In this case the parent combines the content of the CDS records from 
both operators for a while.

	Olafur