Trimmed the cc to avoid cross-posting.
At 11:58 -0400 9/8/09, Paul Wouters wrote:
I guess we need a MUCH better communication method between TLD's, iTAR
and ISC's DLV. This is bad.
What do we need?
(I'm asking in the sense of agreement, but the follow up to this
needs a broader scope. This isn't about the symptoms, it's about
shoring up the operational aspects of DNS such that the security
doesn't break operations.)
The general problem is the transfer of provisioning information from
one zone administration to another. This has been an ignored link,
treated in EPP by RFC 4310, in itself a decent effort but in the
larger scheme of things still a drop in the bucket. (EPP isn't even
from the DNS operator of the child to the DNS operator of the parent,
EPP is between other elements in the food chain.)
When an SEP is minted, the public and private components have to be
provisioned in a number of places. The public key has to get into
the zone. The public and private key files have to be made available
to the signing application. And the public key has to be in position
to become a DS RR and shipped to the parent. This is true whether
the child is a registrant in a registrant-registrar-registry model
and the parent is TLD, or when the child is a TLD and the parent is a
combination of the root zone and a trust anchor repository.
None of these interfaces have been treated by the standards bodies.
When designing a TLDs DNSSEC mechanics the interface and protocol for
publicizing the SEP is still a grey "TBD" box. That's a risk area.
How do we securely automate a DNS provisioning interface/mechanism?
It's more than secure dynamic update.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468
As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
