Subject: [DNSOP] Root key rollover drafts

From: Michael StJohns <[email-masked]>
Date: Mon, 20 Jul 2015 11:31:53 -0400

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

---

From: manning <[email-masked]>
Date: Mon, 20 Jul 2015 08:42:07 -0700

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
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

On 20July2015Monday, at 8:31, Michael StJohns <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 22 Jul 2015 09:50:28 +0200

On Mon, Jul 20, 2015 at 11:31:53AM -0400,
 Michael StJohns <[email-masked]> wrote 
 a message of 41 lines which said:

> We already have a set of formats for trust anchors - DNS master file
> DS and DNSKEY records.  

Do note it is not a new proposal, it is also a documentation of something
that exists but was never documented:

https://data.iana.org/root-anchors/