I think I have to agree with you regarding the level of effort to make a go of this… that said, Joe was/is a member of the ICANN root key rollover team and is likely the spokesmodel for the plan they have come up with. To the extent that this may be true, I believe ICANN is wiling to pay the cost for itself and help defray the cost for the client side.
That said, this approach does shift the risk profile for ICANN, and not in a good way. There is a small, but growing population of folks who believe that diffusion of risk is an attribute of a healthy Internet ecosystem. “To Your Health!" manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 20July2015Monday, at 8:31, Michael StJohns <m...@nthpermutation.com> wrote: > 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
