At-Large

Download

at-large@icann.org

July 2008

34 participants
82 discussions

Re: [At-Large] Safeguarding ICANN Against Capture - Protection contrela subversion de l'ICANN
by Jeffrey A. Williams July 1, 2008

July 1, 2008

JFC and all, ICANN is already captured and has been sense about 2000. Even a casual observer knows this. What's really needed is resting it from the current cabel and restoring it back to the users at large for whom it was largely developed for in the first place. Of course the IPC, BC, and the RC will fight such a notion tooth and toenail. What's amazing about this attitude is it is counter productive in the long run. JFC Morfin wrote: > IIC (Improving Institutional Confidence) should be the main matter of > the preoccupation from now on for those that are interested in ICANN. > I agree with ICANN when they place safeguarding against capture as > their main matter of concern. However, they seem to forget about > resillence and survivability, as if DoS attacks did not exist. > > The first question that we should ask ICANN, and ourselves, should be > about a documented clean slate third party evaluation concerning: > - what is to be captured? > - what is the existing degree of capture? > - what are the various types of possible capture that one might fear? > > When I say documented, I mean to have some barometer about the risks > and degree of capture. For example, ICANN is not worth a penny: > - without the IANA, which is delegated by the USA. I cannot be > certain that I saw a US commitment to transfer the IANA to ICANN. > - if it opposes with IETF. This means that it is dependent on an IETF > capture. This means that the same questions should arise concerning the IETF. > > Relations with IETF are not the only ones to be considered. Actually, > ISOC is far too close to ICANN and IETF in order for the same > questions to not arise. The importance of ICANN, IETF, and ISOC is > such that, as an Internet @large lead user, it is necessary for each > of us to also carry this evaluation. The French Minister for the > Internet has indicated his three main areas of concern: addressing, > naming, and multilingualism. He stated that they will be the basis > for the European Internet Governmental summit of Nice on October 6/7, > 2008 and will decide the November 26, 2008 French-proposed European > Internet Governance Policy. There is no doubt that this European > position will be the main matter at Hyderabad at the Government as > well as Civil Society, Private sector, International organization, > and Research & Normative levels. > > There is a need for an @large debate on this issue. I would like to > know if ALAC wants to host it, if it should be carried through > another, and more open, @large mailing list, website, and wiki, or if > ALAC should envision this issue from inside and if another mailing > list should envision it from the outside? > jfc > > === > > L'ICC (amélioration de la confiance institutionelle) devrait être le > principal sujet de la préoccupation à partir de maintenant pour ceux > qui sont intéressés par l'ICANN. Je suis d'accord avec l'ICANN > lorsqu'ils font de la sauvegarde contre leur capture leur principal > sujet de préoccupation. Toutefois, ils semblent avoir oublié leur > resillence et leur capacité de survie, comme si les attaques DoS > n'existaient pas. > > La première question que nous devrions demander à l'ICANN, et à > nous-mêmes, devrait être une tierce évaluation à partir de zéro concernat : > -- ce qui est à capturer ? > -- quel est le degré de capture existant ? > -- quels sont les différents types de capture possible que l'on peut craindre? > > Quand je dis documentée, ceci concerne une sorte de baromètre sur les > risques et le degré de capture. Par exemple, l'ICANN ne vaut pas un centime: > -- sans l'IANA, qui est délégué par les États-Unis. Je ne suis pas > sûr d'avoir vu un engagement américain de transférer l'IANA à l'ICANN. > -- si elle s'oppose à l'IETF. Cela signifie qu'elle dépend d'une > capture IETF. Cela signifie que les mêmes questions se posent > concernant l'IETF. > > Ses relations avec l'IETF ne sont pas les seulles à devoir être > prises en considération. En fait, l'ISOC est beaucoup trop proche de > l'ICANN et l'IETF pour que les mêmes questions se posent pas. > L'importance de l'ICANN, l'IETF et l'ISOC est telle, pour nous > utilisateurs pilotes @large de l'Internet, qu'il est nécessaire à > chacun d'entre nous de procéder à cette évaluation. Le Ministre > français de l'Internet a indiqué ses trois principaux domaines de > préoccupation: l'adressage, le nommage, et le multilinguisme. Il a > déclaré qu'ils seront la base du sommet gouvernemental sur l'Internet > les 6/7 octobre 2008 et décideront de la proposition française du 26 > Novembre, 2008 pour la politique européenne de Gouvernance de > l'Internet. Il ne fait aucun doute que cette position européenne sera > le principal sujet à Hyderabad aux niveaux gouvernemental, société > civile, secteur privé, organisations internationales, et recherche et > normalisation. > > Un grand débat @large est nécessaire sur cette question. Je voudrais > savoir si l'ALAC veut l'accueillir, si elle devrait être menée par > une autre liste de diffusion @large avec son site web, et son wiki, > ou si l'ALAC devrait envisager cette question de l'intérieur et si > une autre liste devrait l'envisager de l'extérieur? > jfc > > ------------------------------------------------------------------------ > _______________________________________________ > ALAC mailing list > ALAC(a)atlarge-lists.icann.org > http://atlarge-lists.icann.org/mailman/listinfo/alac_atlarge-lists.icann.org > > At-Large Official Site: http://atlarge.icann.org Regards, Spokesman for INEGroup LLA. - (Over 281k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1(a)ix.netcom.com My Phone: 214-244-4827

1 0

DNS Encryption -- IETF Draft
by Evan Leibovitch July 1, 2008

July 1, 2008

Hello, The author of a draft proposal on signed and encrypted DNS has submitted it to the IETF; a link was posted to a Toronto Asterisk (open source VOIP/telephony) mailing list. One of the main purposes of having this facility is to prevent DNS spoofing and "man in the middle" attacks. I thought this may be of interest to our audience: http://www.e164.org/docs/draft-groth-dns-encryption-00.txt One notable aspect of the draft (and a reason for its interest to the open source community) is its use of OpenPGP keys rather than X.509 certificates: > It would be a bad security decision to use X.509 certificates, > SMTP-TLS has shown that very few commercial certificates have been > purchased, most people use self-signed or invalid certificates. Also: > With current threats existing for very short periods, typically hours > to days at most, there is no practical reason for keys to expire in 1 > or even 5 years, the primary reason most certificates expire with such > frequency is due to monetary reason which is detrimental to security. I hope this is of interest. The reason this was sent on a telephony list is because of the use of NAPTR resource records in DNS entries (see RFP 2915) to store telephone/VOIP number names as well as conventional Internet domain names. - Evan

4 3