I'm actually somewhat opposed to adopting Joe's trustanchor draft- I
don't think the cost/benefit analysis works.
We already have a set of formats for trust anchors - DNS master file DS
and DNSKEY records. What the document adds is a signature mechanism
over those items (now formatted as either XML or ASN1) and then
specifies the keys that are allowed to sign the trust anchors. However,
the document completely avoids the question of how those signing keys
are managed and protected, and .... wait for it ... replaced as trusted
signers.
As I said at the microphone, all this does is move the trust problem
back one step (two steps? I think I also have to trust the CA that
issued the PGP keys as well as the owner of the PGP keys) and I'm pretty
sure may have the result of weakening the actual security of the root
for those clients foolish enough to accept the signed data without
having human intervention.
There's a bootstrap problem that is generally solved by putting a human
in the loop to make decisions. When we started this we published far
and wide the hashes of the root trust anchor (KSK) and used that to
bootstrap trust of the root zone. We used the "tell me N times"
approach to data validation and I think we probably did pretty well with
the whole trust establishment across the globe.
To make Joe's approach work, we would need to establish global trust in
the ICANN CA, protect the CA keys and the PGP keys, document the hell
out of how the signing gets done etc. I'm pretty sure this is neither
worth it on the ICANN side (addl root signing costs), nor on the client
side.
Later, Mike
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
