[governance] "Oversight"

McTim dogwallah at gmail.com
Wed Jun 6 10:30:27 EDT 2012


On Wed, Jun 6, 2012 at 4:56 AM, parminder <parminder at itforchange.net> wrote:
>
>
> On Tuesday 05 June 2012 09:17 PM, David Conrad wrote:
>
> Ignoring that, there are technical issues relating to the size of signatures
> that make supporting multiple keys as you suggest quite challenging.
> Revising DNSSEC to add this capability would likely be quite expensive and I
> suspect the cost/benefit analysis would imply it would be difficult to get
> the technical community to revise the specifications, update
> implementations, and deploy the new code, particularly as all that effort
> would need to be done to address a non-technical consideration that most in
> the technical community would view (rightly or wrongly) as political window
> dressing.
>
>
>
>
> That exactly is why technical standards development and CIR requires
> political oversight.


But in your agreements with Bill above I had thought you excluded
standards development from the definiton of "oversight"?


 How can, what you call as, the 'technical community'
> decide that such a matter of utmost importance to people and countries
> outside the US is simply 'political window dressing'.

Because they are volunteers who engineer what they think is the best solution.

You are welcome to join the DNSEXT WG list and state your case and try
to change the DNSSEC protocol.


 It is ridiculous. And
> whose cost/benefit analysis is it? Who decides the social and political
> costs and benefits?

I think that was drc's back of a fag packet calculation.

Mine agreed with his.

Whose political and social interests does this
> 'technical community', which thinks as you say it thinks, represent. If they
> think they are experts in technical matters, can they, by a similar logic,
> allow the possibilities that others may know more than them about social,
> economic, cultural and political matters, and the corresponding costs and
> benefits.

Am sure they will allow that possibility.  That is why you are welcome to join.


>
> This is a misuse of 'technical power' which really is no technical power, it
> is real economic, social and political power masquerading as technical
> power, hiding behind technical people and the so called 'technical
> community' in order to gain some legitimacy, or rather to avoid the blame of
> illegitimacy.

No, I think it is jusr drc telling you that a group of volunteers is
NOT going to undo
15 years of work on their part so that a politically driven,
technically unworkable solution can be implemented.
DNSSEC isn't widely deployed (yet) adding on to it now for political
reasons may just kill any momentum it does have.


>
> And if it is just 'political window dressing' why was the US gov so
> interested in asserting that the current DNSSEC model is what it wants, and
> none of the possible alternatives. And why does US gov want the IANA manager
> to contractually agree that US gov will decide on the chief security officer
> for this function.

Youo'va asserted this before, is this in the NTIA RFP?  Please send me
the link and page number, I haven't seen this!


>
>
> However, I might suggest the focus on DNSSEC in this regard is misplaced. As
> mentioned in a previous note, DNSSEC merely provides the capability to
> verify that a DNS response hasn't been modified from the point at which the
> data was signed by the private key holder to the point where it was
> validated (typically by ISPs). The data first must be created before it can
> be signed.  Once signed it still must be published.  Even if the US were to
> go "rogue", root servers and caches outside the US would hold the pre-rogue
> root zone and it would be straightforward (technically at least) for a new
> signing facility to be established in Geneva, Beijing, or wherever else is
> felt to be more trustworthy.
>
>
> This suggestion is like beginning to set up a fire department when the house
> is on fire. Actors dont go wholesale rogue in the manner you picture it,
> neither is such a radical from-the-scratch response possible in the real
> world. This is a bit of a technical construction of the problem and its
> solution. Actors go rogue in stages, carefully, for their rogue-ness to be
> sustainable. As US has been going rogue on IP related international domain
> seizures, (and attempting to formalise it through SOPA), as in the attempt
> at 'Internet Kill Switch' legislation, as evident with ACTA, with use of
> Stuxnet and flame, formalising un-disclosed security relationships with
> google, facebook, twitter etc, with software companies......  What is your
> criterion for declaring US gone rogue?


Prmndr, it's a binary question, either the USG has tampered with the
rootzone OR it has not.

To date, it has NOT.


I think what drc is trying to tell you  (from his vast firsthand
experience) is that IF in the incredibly unlikely
event that the IANA created a rootzone that excluded say .in AND NTIA
signed off on this change, the TCRs
from around the world would have to fly to a rootsigning ceremony,
recreate the keys that are used to sign the
key that signs the rootzone (a bit of a simplification for ease of
readability), resign the new zone and then send
it to Verisign for publication.

In that incredibly far-fetched scenario, all the root-ops would have
to accept that new zone.  I suggest that at least some would not.


-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel

-------------- next part --------------
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.igcaucus.org
To be removed from the list, visit:
     http://www.igcaucus.org/unsubscribing

For all other list information and functions, see:
     http://lists.igcaucus.org/info/governance
To edit your profile and to find the IGC's charter, see:
     http://www.igcaucus.org/

Translate this email: http://translate.google.com/translate_t


More information about the Governance mailing list