On Mon, 18 Feb 2013, Warren Kumari wrote:
The basic idea remains the same -- allow operators to publish new (and standby)
DS records at the parent by publishing them in their zone, signed with their
current key.
I of course hope this draft or something similar will go through. The
fact that the older CDS draft got stuck was for me the motivation
behind draft-wouters-dnsop-secure-update-use-cases but that seems
stalled by people being ver nervous about the RRR model. I had to
carefully not mention any technology I prefered in that draft, but
this kind of mechanism always had my preference, as it requires no
direct parent-child port 53 access, and signaling between parent
and child an be done my helpers that are not in the actual path of
serving DNS data, so it is also the most secure method of doing it.
What is missing in this draft doing the same for other parent-child
data, such as NS and glue records. Since we have an authenticated
parent-child relationship now, why not extend this draft to include
CNS/GLUEA/GLUEAAAA ? To me it makes sense to integrate it here, because
the mechanism will be basically identical, although perhaps some more
prevention for shooting one's foot might be required.
In many environments (for example, gTLDs) the parent will be a
registry, and is expected to not have direct contact with the child
(registrant).
I recommend removing ANY kind of language that ties anything to the RRR
model, as just mentioning it is what more or less killed the use-cases
draft. That includes mentioning TLDs or "Registry interface". Specify the
protocol, leave out the administration/politics and don't tell people
how to integrate the implementation.
In this case the parental agent will query each child zone that has a
DS RRset, looking for CDS RRset
That's a good mechanism to leave the initial auth specification (tied to
RRR or not) out of the spec! Bravo!
If the validation succeeds with a DNSKEY that is represented
in the current DS RRset in parent.
You have to be more strict then just "validation succeeds". You MUST
ensure the proper DNSKEY's matching the CDS records exist on ALL
secondary servers, and must wait AT LEAST a TTL time before being
willing to update the DS record.
The parenteral agent should
submit a request to the registry to publish the contents of the CDS
RR(s) as the new a DS record(s) for that zone.
But here you go wrong. Rewrite it to not mention "registry". Just talk
about the parent zone manager. You could be talking about an inline
bind, a cron job, some perl code, a database ...whatever the parent is.
The registry should log if possible the source of the update,
user interface/CDS etc.
Same here.
IN CDS 0 0 0
I really dislike this idea. An attacker that has no access to the keys,
but does have access to unsigned zone data could put such a record in
the zone to fully remove the security added by the DNSSEC signer to
which they might not have access (yet). This can cause an escalation
from "needing a still-compromised server" to "only need to compromise a
server briefly and then leave without a trace".
I believe you should stick to out of band communication for both secure->
insecure and insecure -> secure.
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
