On 21/07/2011 7:39 AM, Antoin Verschuren wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11-07-11 11:51, Marc Lampo wrote:
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)
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.
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?
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.
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?
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.
This does not work in all cases, unless the child can control when/if
the parent checks. (think algorithm introduction/retirement)
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 new bit would be better, but you need to think about the semantics.
IMHO CKEY-to-DS is what you want.
A NOTIFY from child to parent may then be sufficient for the parent to
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
NOTIFY ?
(new protocol)
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 ?
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)
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
In this case the parent combines the content of the CDS records from
both operators for a while.
Olafur
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
