On 2014-01-14, at 12:22, Andrew Sullivan <[email protected]> wrote:
> For my sins, I have been following some of the recent discussions > about "Internet governance". One of the discussions over on the > "1net" list (http://1net-mail.1net.org/mailman/listinfo/discuss) is > about the control by one particular government of the DNS root zone, > and how uncomfortable that makes some other governments. The > consequence has been renewed discussion on a somewhat older proposal > for splitting up the management of the root zone keys. The proposal > can be found at > http://www.internetgovernance.org/wordpress/wp-content/uploads/SecuringTheRoot.pdf. It's interesting to see that what was actually built in 2009/2010 is largely compatible (at the high-level diagram level) with what was proposed, except that there's only a single RKO and it's called IANA. The general framework (as deployed today) whereby KSRs are sent from the RZM to the RKO and ceremonies are held at the RKO to process them seems eminently extensible, at least in theory. However, each RKO you add increases the operational risk that an SKR from that RKO might not be obtained within the required window, which puts zone publication in jeopardy. It also adds points where political concerns might lead to a refusal to sign. Since a KSR is not linked to a specific set of proposed changes to the root zone, a refusal to sign would presumably be on general/philosophical grounds rather than in reaction to any particular proposed change to the root zone. Timing for KSK rollover would have to be carefully managed, since it seems like having multiple RKOs roll their KSKs in overlapping windows would be a recipe for grand hilarity. > The proposal has the appealing property that nobody can "hijack" the > root, Well, in fact any RKO can hijack the root (by which I mean put its publication in jeopardy for people validating against that RKO's trust anchor). They can just refuse to process a KSR; during the time window corresponding to that KSR, validators depending solely on that RKO's trust anchor would see the namespace go dark. [If validators took the approach of installing trust anchors from each and every RKO to mitigate this possibility, then they are effectively saying "I'm happy so long as at least one RKO is happy even if all the others are deeply miserable", which doesn't sound like it achieves the document's objectives.] In terms of custody of each KSK, multiple RKOs means multiple opportunities to compromise private key assets. That's a change to the risk profile. Also, one RKO performing key ceremonies is tedious enough, imagine if there were five times as many :-) I realise this wasn't the point you were raising, but I thought it was an interesting tangent. To the point you were actually raising: > I am not sure I am so sanguine, but this put in my mind the > draft-ietf-dnsop-respsize draft, which I now realise was never > published as an RFC. > > I'd like this thread to discuss the "so what, use TCP!" remark. I'd > also like to ask either the chairs or the WG whether > draft-ietf-dnsop-respsize-14 needs revision and, if so, what revision > to be publishable, because I think it's needed advice. I also think that draft should be published. I think we have a little more operational experience with (and studies that speak to) large responses now than we did when Vixie last lifted the pen on that document, so I imagine it would benefit from some review. I would be happy to review and/or contribute. Joe
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
