I just posted a new version:
http://www.ietf.org/internet-drafts/draft-kumari-ogud-dnsop-cds-01.txt
On 19/02/2013 11:07, Paul Wouters wrote:
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 new version this will be hinted at but not explained to constrain scope.
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.
Well the new version has more text not less but hopefully as it all
examples this will not cause problems.
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.
New version says:
If present the Parental Agent MUST validate [<xref
target="RFC4035"></xref>] the CDS RRset. If the validation
succeeds
with a DNSKEY that is represented in the current DS RRset in
parent.
Hope that is strong enough
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.
Attempted to fix this.
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".
If they have that access what stops them then from publishing anything
in the zone, including forged DNAME records?
I believe you should stick to out of band communication for both secure->
insecure and insecure -> secure.
thanks for the good comments.
Olafur
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
