Re: China venue survey
On Wed Sep 23 04:14:26 2009, Peter Saint-Andre wrote: > Indeed, our own meetings are scoped and moderated, You clearly weren't at the Codec BoF. Well, heavy weaponry was declared out of scope. As was reaching any kind of useful decision. > and disruptive > influences can be, and are, removed from mailing lists. (I have no clue > if there's an equivalent to PR actions for physical meetings, but I can > imagine that we might make one up if we needed to). Disruptive as defined by whom? It seems to me that the contract we might sign cedes the definition of disruptive to a government about whose laws we know very little. Do correct me if I'm wrong, but as far as I know the IETF has never before signed a contract that lets the government of the host country define what is and is not an allowable topic for discussion. As other people have said, the much more worrying aspect is that this is a contract with the Hotel. But in the scenario I was suggesting, a person is generally regarded as disruptive as defined by a comparitively small group of people, not including the disruptors themselves. The people we entrust this decision to have, we hope, fairly acceptable views on what disruption is. > On the other hand, I can accept as valid the suggestion that some people > have made that the particular restrictions of speech that the PRC impose > may restrict the scope of discussion that the IETF typically engages in. We don't know if they do or if they don't, without studying the laws of the People's Republic of China. True, but we can find out by simply asking the government and authorities of the People's Republic of China. > I suspect that it may not be so, and would hope that this can be > determined, clearly, and in advance of any decision. Determined by whom, and to whose satisfaction? Determined by the PRC, to our satisfaction. > However, I would note that I'm still concerned about the possible > effects by and on remote participation. But you'll all have read my > other comments, right? The XMPP technology that is used to run jabber.ietf.org includes methods for room moderation, and I suppose that such methods could be invoked. Yes, but again, we have to ensure that the PRC is prepared for potential abuse of this facility, and we have to ensure that the methods for coping with disruption are themselves minimally disruptive, and are acceptable to the PRC. As well as that, we have to ensure that the PRC accepts that the potentially borderline discussion that occur in meetings may also be occuring via the XMPP service, and this nevertheless need to remain available. I don't think - and this is purely my sense of reading the mailing list - that the majority of people would object to a meeting where we couldn't wave political placards demanding whatever. What we do want is to discuss, openly, those topics we have previously been known to discuss, without having to curb the technical content of our discussions purely because of the location. I'm hoping, as I say, that we can obtain clear guidance on these issues directly from the authorities in the PRC. Moreover, I agree with the sense of Pete Resnick's comments, and Dean Willis's, that we should push for clarification and close contact, and remove the Hotel from the chain of enforcement. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAB] Request for community guidance on issue concerning a future meeting of the IETF
On Wed Sep 23 04:45:39 2009, Peter Saint-Andre wrote: > Sigh, I will get a high Narten score this week It's worse if you digitally sign your messages... I always wondered why you did that. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 standard?
Steve et al. thank you for your interesting comments. Being some kind of IPv6 "evangelist", I'll admit it, I do need to gain a feeling of points of view from people who are in the know, and the range of replies in this short thread has been interesting indeed. "Steve Crocker" wrote: The main point I wanted to make is that bringing IPv6 into full use and advancing the associated specifications along the standards track did not, at least for me, imply deprecating IPv4 standards. In practice, the two technologies are going to co-exist for quite a while. The matter came up in an IPv6 discussion ISOC Chapters teleconference call last night. We reached a burning question which nobody could answer factually: Is a dual stack IPv4-IPv6 likely to be more unstable than pure IPv4 or pure IPv6? The rationale behind this comes from the consumer's point of view. If a consumer has problems using Internet services after turning on IPv6 on their computer, they are likely to blame IPv6 for the fault and to turn off IPv6 altogether, thus slowing down adoption. I've heard countless anecdotal stories of that happening, and I wonder whether anybody could point me to a source of information, some kind of repository of anectodal or researched evidence of problems encountered when turning to dual stack IPv4/IPv6. With such problems being encountered with dual stack, would it make sense to deprecating IPv4 standards ASAP in order to shorten the time for use of dual stack and this shorten the likelyhood of consumers being turned off IPv6? Or on the other hand, do you think that the dual stack problems are only small quirks which will be ironed out in time and a stable dual stack IPv4/IPv6 system will soon be possible across all devices? Kindest regards, Olivier -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 standard?
On Wed, Sep 23, 2009 at 11:05:02AM +0200, Olivier MJ Crepin-Leblond wrote: > > The matter came up in an IPv6 discussion ISOC Chapters teleconference call > last night. We reached a burning question which nobody could answer > factually: > > Is a dual stack IPv4-IPv6 likely to be more unstable than pure IPv4 or pure > IPv6? > > > -- > Olivier MJ Cr?pin-Leblond, PhD > http://www.gih.com/ocl.html > Empirical evidence (as documented in the network operational lists over the past 10 years) indicates that dual stack is clearly more unstable. about 3 years ago, I moved my entire dual-stack network to single stack (v6) - with two exceptions... the IVI gateway and the DNS/DHCP server. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: GenArt Telechat Review of draft-ietf-pkix-other-certs-05
Thanks for the review Ben. Couple of comments below. Ben Campbell wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-pkix-other-certs-05 > Reviewer: Ben Campbell > Review Date: 22 Sep 2009 > IESG Telechat date: 24 Sept 2009 > > Summary: This draft is basically ready for publication as an > experimental RFC. I have one concern that might be problematic if this > was standards track, but I suspect would not impact an experimental. > > Issues: > > -- Section 3: > > (I am not an expert on how end-entities are expected to treat expired > certs, so I could easily be confused here) I guess in general that's application specific, e.g. one might want an email UA to use an expired cert to verify a signature on an old, stored message. For HTTP/TLS, I guess one shouldn't see expired certs, though of course one does in fact see that quite a lot;-) However, for the main HTTP/TLS use-case, if all was well when the old cert was seen, then it won't really matter what has happened to the old-cert private key in the meantime since the RP will (usually) only see the new-cert public key and (if all is well with the new-cert private key), the linkage remains safe. If a bad-guy wanted to make use of the leaked old-cert private key, then that's independent of the new extension - the bad guy would just use the leaked old-cert private key and hope that the RP lets the user click on the "accept anyway" button as is currently, unfortunately, the case. Arguably, if RPs supported the new extension, we'd all be better off, since such RPs could maybe enforce old-cert expiry more strictly, but that's something to learn-as-we-go - one of the reasons to do this as experimental I guess. > The draft states that two linked certs do not have to be simultaneously > valid, if an application somehow cached the validity of a currently > expired certificate. The extension asserts that the same end-entity > has the private keys for both linked certs. My concern is the idea that > you can assume that the end-entity that held the private keys for a cert > in the past _still_ holds them after that cert expires. > > The draft goes further to explicitly disallow that assumption in the > case where one of the certs has been revoked. In the case of revocation, > it's reasonable to assume the end-entity no longer has sole possession > of the private key. But can you assume that an end-entity will continue > to securely protect the private-key associated with an expired cert, or > revoke that cert if the key is compromised? This assumption appears to > be fundamental to the primary use case described in the draft. > > I'm not sure if this is a problem, as the operating assumption is > probably along the lines of "the end-entity for this new cert had the > private keys for the expired cert back before it expired". If this were > standards track, it would probably be worth some elaboration in the > security considerations section. I guess I don't really see a problem here either, since the putative problem (leaking private key) would also affect a PKI without this new extension as mentioned above. In fact, even if the cert was revoked, that revocation entry may eventually be dropped from the latest CRL (if the RP depends on CRLs). But just in case this does get promoted later, I'd have no problem adding something like the following at the end of the current security considerations section: "In some application contexts, if the old certificate has expired, (and perhaps any associated CRL entries are no longer on the latest CRL), it may be unsafe to link the new and old certificates. Application developers SHOULD carefully consider whether to make use of the other certificates extension in such contexts." I'll leave it to the AD/IESG to say whether its worthwhile adding text like that or not. > > > Nits/editorial comments: > > -- Section 8, last paragraph, last sentence: > > Duplicate "." (period) Ta. > > -- idnits reports the following: > > The document seems to lack a disclaimer for pre-RFC5378 work, but was > first submitted before 10 November 2008. Should you add the > disclaimer? Nope. > (See the Legal Provisions document at > http://trustee.ietf.org/license-info for more information.). > Regards, Stephen. > > > > > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: GenArt Telechat Review of draft-ietf-pkix-other-certs-05
Thanks for the quick response. Your responses address all of my comments. Thanks! Ben. On Sep 23, 2009, at 5:52 AM, Stephen Farrell wrote: Thanks for the review Ben. Couple of comments below. Ben Campbell wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-pkix-other-certs-05 Reviewer: Ben Campbell Review Date: 22 Sep 2009 IESG Telechat date: 24 Sept 2009 Summary: This draft is basically ready for publication as an experimental RFC. I have one concern that might be problematic if this was standards track, but I suspect would not impact an experimental. Issues: -- Section 3: (I am not an expert on how end-entities are expected to treat expired certs, so I could easily be confused here) I guess in general that's application specific, e.g. one might want an email UA to use an expired cert to verify a signature on an old, stored message. For HTTP/TLS, I guess one shouldn't see expired certs, though of course one does in fact see that quite a lot;-) However, for the main HTTP/TLS use-case, if all was well when the old cert was seen, then it won't really matter what has happened to the old-cert private key in the meantime since the RP will (usually) only see the new-cert public key and (if all is well with the new-cert private key), the linkage remains safe. If a bad-guy wanted to make use of the leaked old-cert private key, then that's independent of the new extension - the bad guy would just use the leaked old-cert private key and hope that the RP lets the user click on the "accept anyway" button as is currently, unfortunately, the case. Arguably, if RPs supported the new extension, we'd all be better off, since such RPs could maybe enforce old-cert expiry more strictly, but that's something to learn-as-we-go - one of the reasons to do this as experimental I guess. The draft states that two linked certs do not have to be simultaneously valid, if an application somehow cached the validity of a currently expired certificate. The extension asserts that the same end-entity has the private keys for both linked certs. My concern is the idea that you can assume that the end-entity that held the private keys for a cert in the past _still_ holds them after that cert expires. The draft goes further to explicitly disallow that assumption in the case where one of the certs has been revoked. In the case of revocation, it's reasonable to assume the end-entity no longer has sole possession of the private key. But can you assume that an end-entity will continue to securely protect the private-key associated with an expired cert, or revoke that cert if the key is compromised? This assumption appears to be fundamental to the primary use case described in the draft. I'm not sure if this is a problem, as the operating assumption is probably along the lines of "the end-entity for this new cert had the private keys for the expired cert back before it expired". If this were standards track, it would probably be worth some elaboration in the security considerations section. I guess I don't really see a problem here either, since the putative problem (leaking private key) would also affect a PKI without this new extension as mentioned above. In fact, even if the cert was revoked, that revocation entry may eventually be dropped from the latest CRL (if the RP depends on CRLs). But just in case this does get promoted later, I'd have no problem adding something like the following at the end of the current security considerations section: "In some application contexts, if the old certificate has expired, (and perhaps any associated CRL entries are no longer on the latest CRL), it may be unsafe to link the new and old certificates. Application developers SHOULD carefully consider whether to make use of the other certificates extension in such contexts." I'll leave it to the AD/IESG to say whether its worthwhile adding text like that or not. Nits/editorial comments: -- Section 8, last paragraph, last sentence: Duplicate "." (period) Ta. -- idnits reports the following: The document seems to lack a disclaimer for pre-RFC5378 work, but was first submitted before 10 November 2008. Should you add the disclaimer? Nope. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.). Regards, Stephen. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 standard?
Olivier MJ Crepin-Leblond wrote: > Is a dual stack IPv4-IPv6 likely to be more unstable than pure IPv4 or pure > IPv6? Just from a pure software-engineering standpoint, with no reference to the stability of current stacks nor the exact tasks at hand, it seems quite likely. More code, doing more stuff, generally means more things that can go wrong. -Dave -- Dave Aronson, software engineer or trainer for hire. Looking for job (or contract) in Washington DC area. See http://davearonson.com/ for resume & other info. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAB] Request for community guidance on issue concerning a future meeting of the IETF
On 9/22/09 22:42, Sep 22, Ole Jacobsen wrote: I see absolutely NOTHING in the transcript of the IETF 75 session on net neutrality that I would consider disrespectful or demfamatory of any government. The problem is that you're looking for a needle in the portion of a haystack that happens to have been recorded; finding none, you declare the haystack needle free. In my recollection, there is a semi-regular IETF participant who travels with a MacBook that has a Tibetan flag sticker prominently visible on the lid. Hopefully, someone with the political awareness to make that kind of statement also has the political awareness to recognize that bringing a laptop so decorated into the PRC is likely to cause an incident. On the other hand, someone with the value system to make that kind of statement may welcome such an incident. The clause under discussion runs headlong into this kind of problem and amplifies it by potentially shutting down the entire event. And that's just the needle in this haystack that I can remember, unaided, without the assistance of transcripts or surveillance of any kind. You're comfortable that it's the only needle? You have lot of faith. /a ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
At Tue, 22 Sep 2009 22:22:31 -0500, Pete Resnick wrote: > On 9/22/09 at 2:50 PM -0400, Ray Pelletier wrote: > > >The language in the contract is a statement of the law and is > >intended to put the Host and group on notice of such. If the > >language were not in the contract, it would still be the law. > > Certainly the part about "defamation", "show any disrespect", and > "violates any laws" (which, according to Marshall's original message, > includes certain politicial statements and protest marches) are > clearly a statement of the law as others have explained in this > thread. I've heard nothing so far that indicates that the rest of the > clause (with regard to terminating the event or the hotel or host > having responsibility for the enforcement) is any part of the law. This is exactly right. Reasoning by analogy is always dangerous, but let me suggest an analogy: say that we wanted to have an IETF in an area that had a lot of hurricanes. Now, the likelihood of a hurricane is not something we can control--I don't expect to negotiate with national law--but the extent to which it effects the IETF is at least partly within the hotel's control. So, one could imagine a number of clauses about what happens in the event of a hurricane in which the hotel becomes unusable: - The event is cancelled and lose all our money. - The event is cancelled but the hotel refunds a prorated portion of our money. - The event is cancelled but the hotel pays a large indemnity (thus allowing us to have a replacement event). Note that we can't get rid of the risk of hurricanes, but we can control who bears that risk. Now, this isn't a perfect analogy, since in the case of an IETF meeting, we do have limited control of the risk of the meeting being cancelled (though the IETF's control of it is really extremely limited, since they have such limited control over their members) and since the hotel's control over the situation is probably more limited here--but whether they unilaterally cancel the meeting at any hint of wrongdoing is likely to be in their control. However, I think the basic point remains: this contract seems to make the host and the IETF bear a large amount of risk which could be shifted to others. It's not at all clear to me that that point can't be negotiated with the hotel. Why would that be dictated by the Chinese government? -Ekr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
At Mon, 21 Sep 2009 07:01:22 -0700 (PDT), Ole Jacobsen wrote: > > > On Mon, 21 Sep 2009, Eric Rescorla wrote: > > > I'm not really following you here. I've read the stated contract > > terms and I'm concerned that they prohibit activities which may > > reasonably occur during IETF. Are you saying: > > > > (a) No, they don't prohibit those activities. > > (b) Yes, they do prohibit those activities, but they won't actually > > be enforced that way. > > > > If you're saying (a), I'd be interested in seeing your analysis of > > why that is the case, since my own analysis indicates the contrary. > > Indeed, it seems to me that this very discussion we are having now > > (which clearly is an appropriate IETF discussion), violates a number > > of the terms. > > What I am saying is (c) that you have listed a set of topics and > concluded that they violate the contract, I don't agree. I'm sorry, I don't see the difference between (a) and (c). Either our activities violate the language of the contract or they don't. You say that you don't agree that our activities violate the language. If so, that's good news, but it would help if you shared your analysis so that people who are concerned can come to the same conclusion as you. > I have stated > what I believe to be the INTENTION of the language in the contract, > namely prevent political protest at the meeting. I have now attended > 68 out of 75 IETF meetings, but I have never seen "political protest" > of the form that I think might lead to a meeting being shut down in > China. Yes, we are a rowdy bunch at times, and we discuss a lot of > technical things that spill over into layer 9, but let me repeat what > I said earlier: There is no way the host, with the understanding of > the government, would invite us to meet in China if they expected us > to: > > a) Not discuss our usual topics > b) Stage a political rally > > The offending hotel clause, simply put, is a reminder of b. Now I'm really confused, because *this* sounds like my alternative (b) above. Perhaps what you're saying here is that (1) the contract doesn't prohibit these activities and (2) even if if did, our counterparties can be trusted not to interpret it in a way we would find objectionable. If so, I have to say I don't find this particularly comforting: as I've seen no analysis to support (1) [and several analysis which suggest the contrary], and (2) relying on intentions rather than contract language seems like an extraordinarily unsafe practice given the costs to us of having a meeting cancelled (even if we're not on the hook for paying the hotel a bunch of money). -Ekr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 standard?
In message <3f4922c70909230624p6653f9dckbac05e0465ea9...@mail.gmail.com>, IETF M ember Dave Aronson writes: > Olivier MJ Crepin-Leblond wrote: > > > Is a dual stack IPv4-IPv6 likely to be more unstable than pure IPv4 or pure > > IPv6? > > Just from a pure software-engineering standpoint, with no reference to > the stability of current stacks nor the exact tasks at hand, it seems > quite likely. More code, doing more stuff, generally means more > things that can go wrong. > > -Dave It also depends on how you turn it on. If you only have local IPv6 connectivity it is more problematic than if you have global IPv6 connectivity. Dual stack also tends to discovers all the applications which really don't support connecting to multi-homed machines correctly. This is more true when you only have local connectivity. That being said I've run dual stack for the last 5 years without much in the way of problems. My IPv6 connectivity is a tunnel across the Pacific and when the tunnel goes down about the only thing I notice is slower connections which would probably go if I was to run a routing protocol over the tunnel. Mark > -- > Dave Aronson, software engineer or trainer for hire. > Looking for job (or contract) in Washington DC area. > See http://davearonson.com/ for resume & other info. > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China venue survey
On Sep 22, 2009, at 10:14 PM, Peter Saint-Andre wrote: I'm not talking about incitement to riot, advocacy of terrorism, expressions of racial hatred, or anything of the kind. As I have expressed several times in this thread, I'm talking about discussion of technical topics that impinge on the political realm: things like the use of encryption to protect personal privacy (especially from the prying eyes of Isaac and Justin), the Internet as a technology that routes around censorship as damage, and the simple human right to be *left alone* by government bureaucrats and other such busybodies if one is going about one's business in a peaceful manner. Concrete example: Would a presentation on how tor was used to bypass state controls on news during the recent election protests in Iran be acceptable under the terms of the agreement? That would sound like a perfectly appropriate and timely plenary presentation. And it seems to me to violate the plain language of the agreement concerning "human rights". ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAB] Request for community guidance on issue concerning a future meeting of the IETF
Adam Roach allegedly wrote on 09/23/2009 9:28 AM: > In my recollection, there is a semi-regular IETF participant who travels > with a MacBook that has a Tibetan flag sticker prominently visible on > the lid. Assuming you are correct, that is an individual statement. It will not be part of presentations, distributed materials, or even discussion sponsored by the meeting. > On the other hand, someone with the value system to make that kind of > statement may welcome such an incident. The clause under discussion runs > headlong into this kind of problem and amplifies it by potentially > shutting down the entire event. Based on the little I've seen of PRC government responses to impromptu protests (I've never been in one but I have firsthand reports), they haven't blamed the organization those people were part of (just the individuals) unless it was significant, pre-planned, and the organization expected something of that kind to occur. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China venue survey
On Wed, 23 Sep 2009, Ben Campbell wrote: > > Concrete example: > > Would a presentation on how tor was used to bypass state controls on > news during the recent election protests in Iran be acceptable under > the terms of the agreement? > > That would sound like a perfectly appropriate and timely plenary > presentation. And it seems to me to violate the plain language of > the agreement concerning "human rights". > I am going to assume that such a presentation would be largerly technical, a case study with some political overtones, but technical nonetheless. I would not expect this to get you in trouble, no. Now, if you were to call the China Daily in advance and announce that you intented to reveal (new) methods for circumventing state laws and you declared this an open BOF where members of the public were invited to come and listen to your (I am assuming) perfect Mandarin, then I can imagine you would politely be asked to refrain from this activity. I am sure we can dream up other scenarioes, but at the risk of repeating myself: in the 68 meetings of the IETF that I have attended, I've never observed activity that would cause concern in the context that we are discussing. Ole ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China venue survey
Speaking just for myself. On Sep 23, 2009, at 9:56 AM, Ben Campbell wrote: On Sep 22, 2009, at 10:14 PM, Peter Saint-Andre wrote: I'm not talking about incitement to riot, advocacy of terrorism, expressions of racial hatred, or anything of the kind. As I have expressed several times in this thread, I'm talking about discussion of technical topics that impinge on the political realm: things like the use of encryption to protect personal privacy (especially from the prying eyes of Isaac and Justin), the Internet as a technology that routes around censorship as damage, and the simple human right to be *left alone* by government bureaucrats and other such busybodies if one is going about one's business in a peaceful manner. Concrete example: Would a presentation on how tor was used to bypass state controls on news during the recent election protests in Iran be acceptable under the terms of the agreement? I don't see why not. We have been invited to come. IETF's talk about these sorts of things as part of our technical discussions. Our hosts know this, and must be prepared for it. I would have no hesitation in giving such a talk myself, if I felt it was appropriate on technical grounds (and if the topic was appropriate in terms of the IETF process, WG charter, plenary session topic, etc.). Note, by the way, that technical knowledge is almost always a double edged sword. What you see as a survey of means to escape censorship others might see as a survey of means to improve censorship. When I gave talks about arms control, I always saw people from "the other side" in attendance. I would assume that the same is true here. Regards Marshall That would sound like a perfectly appropriate and timely plenary presentation. And it seems to me to violate the plain language of the agreement concerning "human rights". ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAB] [rfc-i] path forward with RFC 3932bis
--On Wednesday, September 23, 2009 08:02 +0300 Jari Arkko wrote: >... > I came up with some ways of changing the text, e.g., just > saying "work done in the IETF" and dropping the word > "community". However, is not clear to me that any other words > couldn't be misunderstood in the similar manner. In addition, > if we dropped the word community, would this mean that a BOF > that is about to be chartered as an official working group > would not count as an IETF activity yet? For better or worse, a group that is putting together a BOF under current rules -- applications, posting of draft agendas and sometimes even charters, etc.-- represents considerable work "done in the IETF. One that is about to be chartered is even further along. The problem area, wrt either the IRTF or Independent Submissions, is when someone has sort of started thinking that it might be a good idea for the IETF to do some work in the area... someday. That isn't "work in the IETF" because no real work has been done and the text doesn't say "speculation about possible work in the IETF". Expanding to "the IETF community" might bring in the speculations, organizations that use IETF documents but are not the IETF itself, etc. There is obviously still a gray area there, but I'm inclined to trust the IESG's discretion -- and the problem resolution procedure-- rather than trying to nail down every boundary case. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Security (TLS) Extensions: Extension Definitions) to Proposed Standard
I am aware that the IETF-wide last call has ended, but Daniel Black provided a suggestion (posted on the gnutls-devel list) for the Security Considerations that I agree with and believe can be important. Quoting him, slightly reworded: also maybe 11.1. could say, in response to the last paragraph of section 3, + "Server applications SHOULD validate server_name against any application layer equivalent field." The last paragraph of section 3 reads: If an application negotiates a server name using an application protocol and then upgrades to TLS, and if a server_name extension is sent, then the extension SHOULD contain the same name that was negotiated in the application protocol. If the server_name is established in the TLS session handshake, the client SHOULD NOT attempt to request a different server name at the application layer. It appears security relevant for the server to actual verify that the client do not use another server name at the application layer to circumvent authorization decisions. I cannot find any MUST/SHOULD requirement in the document for servers to test this right now. One attack could works like this: 1) Client establish an client-authenticated HTTPS session with a TLS SNI for blog.example.org and sends a HTTP GET with a Host: header for internal-website.example.org. 2) The server TLS code authenticate and authorize the client (using the certificate) for use with the blog.example.org domain. The server HTTP code serves the internal-website.example.org web page to the client. This system would be insecure but still compliant with RFC 4366bis as far as I can tell, which seems suboptimal. Adding a requirement for servers to check for this attack would solve the problem. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Important Information about IETF 76 Meeting Registration
I have asked Osamu and Kato to answer. Stay tuned. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Wed, 23 Sep 2009, Samuel Weiler wrote: > I'm interested in the answers to the questions asked by EKR a couple of weeks > ago... > > I'd also like to know which frequency band these tags use: are these 125kHz or > 13.56MHz tags? > > -- Sam > > On Mon, 7 Sep 2009, Eric Rescorla wrote: > > > Alexa, > > > > Can you clarify what, if any, the security properties of this system > > are: > > > > In particular: > > > > 1. Will the RFID tag in question respond to any reader or just those > > controlled by the secretariat? > > 2. Is the information on the tag in the clear or encrypted? > > > > My general experience with RFID systems suggests that the answer to > > these questions is likely to be "yes" and "in the clear", but I'd > > certainly be pleasantly surprised to hear otherwise. > > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Hiroshima IETF Codesprint
Hiroshima IETF Codesprint When: November 7, 2009, begining at 9:30 AM Where: IETF Hotel What: A bunch of hackers get together to work on code for the IETF. Some people may be porting of existing functionality to the new framework; some people may be adding exciting new functionality. All code will become part of the open source IETF tools. Who: Hopefully you can help Many of the results of previous codesprint activities are being used every day by the IETF community. Chris Newman and Steve Conte will be helping with advance planning. Henrik Levkowetz will be coordinating the event in Hiroshima. More information is available at: http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF76Sprint If you are able to participate, please sign up on the wiki at: http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF76SprintSignUp Please support the tools development effort, Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
On Wed, 23 Sep 2009, Eric Rescorla wrote: > I'm sorry, I don't see the difference between (a) and (c). Either our > activities violate the language of the contract or they don't. You say > that you don't agree that our activities violate the language. If so, > that's good news, but it would help if you shared your analysis so > that people who are concerned can come to the same conclusion as you. A litte bit of context is always helpful. Notice that the first sentence in the clause says "...defamation against the Government of the People's Republic of China..." Discussing encryption and its uses, for example, is not defamation fo any government unless you set it up as laundry list of "what's wrong with this country" (for any value of country) which isn't something you typically do at the IETF. > > > a) Not discuss our usual topics > > b) Stage a political rally > > > > The offending hotel clause, simply put, is a reminder of b. > > Now I'm really confused, because *this* sounds like my alternative > (b) above. > > Perhaps what you're saying here is that (1) the contract doesn't > prohibit these activities and (2) even if if did, our counterparties > can be trusted not to interpret it in a way we would find > objectionable. If so, I have to say I don't find this particularly > comforting: as I've seen no analysis to support (1) [and several > analysis which suggest the contrary], and (2) relying on intentions > rather than contract language seems like an extraordinarily unsafe > practice given the costs to us of having a meeting cancelled (even > if we're not on the hook for paying the hotel a bunch of money). Any language in any law or contract in any context is subject to interpretation and judgement. > > -Ekr > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
At Wed, 23 Sep 2009 10:15:05 -0700 (PDT), Ole Jacobsen wrote: > > > On Wed, 23 Sep 2009, Eric Rescorla wrote: > > > I'm sorry, I don't see the difference between (a) and (c). Either our > > activities violate the language of the contract or they don't. You say > > that you don't agree that our activities violate the language. If so, > > that's good news, but it would help if you shared your analysis so > > that people who are concerned can come to the same conclusion as you. > > A litte bit of context is always helpful. Notice that the first > sentence in the clause says "...defamation against the Government > of the People's Republic of China..." > > Discussing encryption and its uses, for example, is not defamation fo > any government unless you set it up as laundry list of "what's wrong > with this country" (for any value of country) which isn't something > you typically do at the IETF. Uh, that clause is ORed with other clauses: "Should the contents of the Group's activities, visual or audio presentations at the conference,or printed materials used at the conference (which are within the control of the Client) contain any defamation against the Government of the People's Republic of China, or show any disrespect to the Chinese culture, or ^^ ^^ violates any laws of the People's Republic of China or feature ^^ any topics regarding human rights or religion without prior approval from the Government of the People's Republic of China, the Hotel reserves the right to terminate the event on the spot and/or ask the person(s) who initiates or participates in any or all of the above action to leave the hotel premises immediately. So, this isn't really that useful context for the rest of the paragraph. To take the example of encryption, Ithink people were arguing that it was a topic "regarding human rights". With that said, it's not clear to me that saying "China's policy of censoring the Internet sucks" isn't defamation. > > > a) Not discuss our usual topics > > > b) Stage a political rally > > > > > > The offending hotel clause, simply put, is a reminder of b. > > > > Now I'm really confused, because *this* sounds like my alternative > > (b) above. > > > > Perhaps what you're saying here is that (1) the contract doesn't > > prohibit these activities and (2) even if if did, our counterparties > > can be trusted not to interpret it in a way we would find > > objectionable. If so, I have to say I don't find this particularly > > comforting: as I've seen no analysis to support (1) [and several > > analysis which suggest the contrary], and (2) relying on intentions > > rather than contract language seems like an extraordinarily unsafe > > practice given the costs to us of having a meeting cancelled (even > > if we're not on the hook for paying the hotel a bunch of money). > > Any language in any law or contract in any context is subject to > interpretation and judgement. Sure. I'll rephrase my question then: Is your claim that you believe that the contract would not be found in a court of law to cover the described activities? -Ekr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-sasl-scram
I have noticed an additional problem related to additional data in SCRAM. RFC 4422 section 5 item 2b says: b) An indication of whether the server is expected to provide additional data when indicating a successful outcome. If so, if the server sends the additional data as a challenge, the specification MUST indicate that the response to this challenge is an empty response. As far as I can tell, SCRAM does not specify that the response to a server-final sent as a challenge MUST be an empty client response. This violates the requirements in RFC 4422 for new mechanisms. Review section 3 of RFC 4422 before reading on. SCRAM negotiations in general will look like: C: Request authentication exchange S: Empty Challenge C: SCRAM client-first S: SCRAM server-first C: SCRAM client-final S: SCRAM server-final C: Empty Response S: Outcome of authentication exchange (Four round-trips, ouch!) If the application protocol supports additional data together with outcome of authentication exchange, the negotiation will look like: C: Request authentication exchange S: Empty Challenge C: SCRAM client-first S: SCRAM server-first C: SCRAM client-final S: Outcome of authentication exchange with SCRAM server-final If the application protocol supports optional initial responses, the negotiation will look like: C: Request authentication exchange with SCRAM client-first S: SCRAM server-first C: SCRAM client-final S: SCRAM server-final C: Empty Response S: Outcome of authentication exchange If the application protocol supports both additional data together with outcome of authentication exchange AND optional initial response, the negotiation will look like: C: Request authentication exchange with SCRAM client-first S: SCRAM server-first C: SCRAM client-final S: Outcome of authentication exchange with SCRAM server-final I believe section 5 needs to be rewritten to take all these variants into account. Right now the wordings all assume the last situation. OLD: First, the client sends the "client-first-message" containing: NEW: If the application protocol does not support optional initial responses, the client will request authentication and the first server challenge MUST be empty. The first non-empty client response is the "client-first-message" containing: OLD: The server verifies the nonce and the proof, verifies that the authorization identity (if supplied by the client in the first message) is authorized to act as the authentication identity, and, finally, it responds with a "server-final-message", concluding the authentication exchange. NEW: The server verifies the nonce and the proof and that the authorization identity (if supplied by the client in the first message) is authorized to act as the authentication identity. If the application protocol supports sending outcome of the authentication exchange, it sends the outcome together with the "server-final-message", concluding the exchange. Otherwise, the server sends the "server-final-message" as a request. OLD: The client then authenticates the server by computing the ServerSignature and comparing it to the value sent by the server. If the two are different, the client MUST consider the authentication exchange to be unsuccessful and it might have to drop the connection. NEW: The client then authenticates the server by computing the ServerSignature and comparing it to the value sent by the server. If the two are different, the client MUST consider the authentication exchange to be unsuccessful and it might have to drop the connection. If the application protocol does not support sending additional data together with the outcome of authentication, the client MUST respond to the server request with a empty response. Note that this problem have consequences for my implementation: the earlier SCRAM traces I posted are incorrect since they do not have a final empty client response. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
On Wed, 23 Sep 2009, Eric Rescorla wrote: > So, this isn't really that useful context for the rest of the > paragraph. To take the example of encryption, I think people > were arguing that it was a topic "regarding human rights". > > With that said, it's not clear to me that saying "China's policy > of censoring the Internet sucks" isn't defamation. I would say that this DOES border on defamation, BUT I am at a loss to understand why such a statement would be a required part of our technical discussion. The statement is an opinion about a topic which there is a lot more that can be said, but like the baby said "this isn't the venue." (Let's just say that it isn't well understood in the west). "X policy sucks" sound like politics and not technology particularly if X is a country. If on the other hand you were to say: "I am upset about the way provider Y in country X does aggregation in BGP because this degrades performance of..." you would have little to worry about beyond perhaps a technical argument. I managed to shame a certain provider in India into fixing their issue after they showed up as "most unstable AS" for a number of months, and they ended up thanking me for it in the end after considerable finger pointing. > > I'll rephrase my question then: > Is your claim that you believe that the contract would not be > found in a court of law to cover the described activities? > If by "activities" you mean "technical discussions" that are a normal part of any IETF meeting, then yes. If, on the other hand, you mean using the IETF as a platform to publically criticize the host country, then I would say we are needlessly pushing the envelope. (I don't a court would really enter into it, but that's another matter). Ole ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
At Wed, 23 Sep 2009 11:17:04 -0700 (PDT), Ole Jacobsen wrote: > > > > On Wed, 23 Sep 2009, Eric Rescorla wrote: > > > So, this isn't really that useful context for the rest of the > > paragraph. To take the example of encryption, I think people > > were arguing that it was a topic "regarding human rights". > > > > With that said, it's not clear to me that saying "China's policy > > of censoring the Internet sucks" isn't defamation. > > I would say that this DOES border on defamation, BUT I am at a loss > to understand why such a statement would be a required part of our > technical discussion. The statement is an opinion about a topic which > there is a lot more that can be said, but like the baby said "this > isn't the venue." (Let's just say that it isn't well understood in > the west). "X policy sucks" sound like politics and not technology > particularly if X is a country. Sure, but I've heard plenty of stuff like this said in the IETF, indeed in this very discussion. So, while you may not think that those are appropriate statements, ISTM that we do in fact have a situation in which common IETF speech potentially runs afoul of this restriction. > If on the other hand you were to say: "I am upset about the way > provider Y in country X does aggregation in BGP because this degrades > performance of..." you would have little to worry about beyond perhaps > a technical argument. I'm not a lawyer, but my understanding is that this is in fact defamatory speech within the legal sense that prevails in the US. (That doesn't make it illegal in the US. First Amendment, etc.) > > I'll rephrase my question then: > > Is your claim that you believe that the contract would not be > > found in a court of law to cover the described activities? > > > > If by "activities" you mean "technical discussions" that are a normal > part of any IETF meeting, then yes. In that case, can you please post your analysis of the other ORed parts of the original clause that supports that conclusion? -Ekr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/23/09 12:17 PM, Ole Jacobsen wrote: > > On Wed, 23 Sep 2009, Eric Rescorla wrote: > >> So, this isn't really that useful context for the rest of the >> paragraph. To take the example of encryption, I think people >> were arguing that it was a topic "regarding human rights". >> >> With that said, it's not clear to me that saying "China's policy >> of censoring the Internet sucks" isn't defamation. > > I would say that this DOES border on defamation, BUT I am at a loss > to understand why such a statement would be a required part of our > technical discussion. The statement is an opinion about a topic which > there is a lot more that can be said, but like the baby said "this > isn't the venue." (Let's just say that it isn't well understood in > the west). "X policy sucks" sound like politics and not technology > particularly if X is a country. > > If on the other hand you were to say: "I am upset about the way > provider Y in country X does aggregation in BGP because this degrades > performance of..." you would have little to worry about beyond perhaps > a technical argument. Here's the rub. In the heat of the moment during a given technical discussion, someone might come up to the mic and blurt out "it sucks that countries like X enforce policy Y and IETF technologies need to provide a way for end users to route around that kind of interference with their sacred human right to freedom of unfettered communication". But now that person probably won't come up to the mic for fear of being carted away if they don't phrase things very carefully. People who show up at IETF meetings are simply not in the habit of self-censoring in this way, which means that they probably won't come up to the mic at all if they fear that a topic might be forbidden or dangerous. This climate of fear and self-censorship is a problem. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq6aWcACgkQNL8k5A2w/vwdggCg3q68Ck49RDUaDvj0gct8lEEP eL4AmwVxZN7ru8StrRZvaJBn2aHZLY3n =dRMx -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
At 02:17 PM 9/23/2009, Ole Jacobsen wrote: >BUT I am at a loss >to understand why such a statement would be a required part of our >technical discussion. And I'm at a loss to understand why censoring such a statement (or ejecting an individual who says it, or terminating the IETF meeting in which is was said) should be a required part of an IETF meeting? This isn't a China issue per se - this is about what we expect from and for ourselves in the context of the IETF. We have a way of interacting that - while not pretty - mostly works. It's unclear to me why we should accept restrictions on that way of interacting that are imposed from without. If your answer is - "because there's some benefit to the IETF" - I would then ask what else should we be willing to give up for other benefits and where should we draw the line? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Security (TLS) Extensions: Extension Definitions) to Proposed Standard
At Wed, 23 Sep 2009 15:04:00 -0400 (EDT), Dean Anderson wrote: > > Is that insecure? > > If the client is authorized by certificate, then it seems that it has > that identity in addition to any application level identities. > > The only insecurity is if the certifiate private key has been > compromised, which isn't something that TLS can protect against. > > One problem with using TLS for virtual web hosts is that the server > names cannot match the single name allowed in the certificate. I don't > want to see that get worse; I'd like to see it get better. The server_name extension [RFC 4366] allows this. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
Mike, My answer is that this is a judgement call and it forms part of the decision making tree that the IAOC has to make when selecting any venue. We have asked for community feedback in this case, and we've received it (or we are receiving it I should say). Personally, yes, I see the benefits and I also don't believe that we really WOULD run afoul of the "rules" and suffer any consequences, but one can always come up with worst-case scenarios. If we all go there with self-censorship and fear in mind, I'd rather we went somewhere else, but I don't believe we need to be fearful. Ole On Wed, 23 Sep 2009, Michael StJohns wrote: > > And I'm at a loss to understand why censoring such a statement (or > ejecting an individual who says it, or terminating the IETF meeting > in which is was said) should be a required part of an IETF meeting? > > This isn't a China issue per se - this is about what we expect from > and for ourselves in the context of the IETF. We have a way of > interacting that - while not pretty - mostly works. It's unclear to > me why we should accept restrictions on that way of interacting that > are imposed from without. If your answer is - "because there's some > benefit to the IETF" - I would then ask what else should we be > willing to give up for other benefits and where should we draw the > line? > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
On Sep 23, 2009, at 2:23 PM, Eric Rescorla wrote: At Wed, 23 Sep 2009 11:17:04 -0700 (PDT), Ole Jacobsen wrote: On Wed, 23 Sep 2009, Eric Rescorla wrote: So, this isn't really that useful context for the rest of the paragraph. To take the example of encryption, I think people were arguing that it was a topic "regarding human rights". With that said, it's not clear to me that saying "China's policy of censoring the Internet sucks" isn't defamation. I would say that this DOES border on defamation, BUT I am at a loss to understand why such a statement would be a required part of our technical discussion. The statement is an opinion about a topic which there is a lot more that can be said, but like the baby said "this isn't the venue." (Let's just say that it isn't well understood in the west). "X policy sucks" sound like politics and not technology particularly if X is a country. Sure, but I've heard plenty of stuff like this said in the IETF, indeed in this very discussion. So, while you may not think that those are appropriate statements, ISTM that we do in fact have a situation in which common IETF speech potentially runs afoul of this restriction. If on the other hand you were to say: "I am upset about the way provider Y in country X does aggregation in BGP because this degrades performance of..." you would have little to worry about beyond perhaps a technical argument. I'm not a lawyer, but my understanding is that this is in fact defamatory speech within the legal sense that prevails in the US. (That doesn't make it illegal in the US. First Amendment, etc.) I'll rephrase my question then: Is your claim that you believe that the contract would not be found in a court of law to cover the described activities? If by "activities" you mean "technical discussions" that are a normal part of any IETF meeting, then yes. In that case, can you please post your analysis of the other ORed parts of the original clause that supports that conclusion? Dear Eric; As far as I know, you are not a lawyer (please correct me if I am wrong). I am not a lawyer. Ole is not a lawyer. What use is any of us doing this analysis ? I might as well ask the IETF Counsel to produce a technical analysis of LISP-ALT. I don't think that this will get us anywhere. Furthermore, my experience with lawyers is that they will rarely, if ever, in any legal system provide you with guarantees. They can point out problems, but you have to use judgement to decide what to do. A long time ago, I learned that the letter of legal agreements is in many cases less important than the intent of the parties. There are always issues in any agreement, and you can always "war-game" possible breakdowns. The real question is, is there intent to do what is agreed upon (and, do you both agree what that is) ? I think there is intent, in inviting us to China, for us to have a good and productive meeting in China. I think that all parties (us, the host, the Hotel, and the government) want this result. My judgement is therefore that we would not be found in breach of the contract by the hotel for any activities I have seen in 10 years of IETFs. That is not a legal analysis, but it is my considered opinion, based on all of the facts available to me, and my reading of the intent of the parties. Others, such as Ole, with much more experience with the PRC than I do have come to the same conclusion. Everyone is of course free to come their own conclusions, but this is how I came to mine. Regards Marshall -Ekr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China venue survey
I am going to assume that such a presentation would be largerly technical, a case study with some political overtones, but technical nonetheless. I would not expect this to get you in trouble, no. A very basic problem with these sorts of assurances is that they are being made by people who do, and cannot, not speak for the government or hotel management. We really need to avoid the tendency to idealize what can go wrong or right, particularly in the absence of serious information. We need to avoid the desire to interpret the language or possible actions according to what we, ourselves, might do. We need to interpret things from the perspective of the folks who will be the principal actors, defined in the agreement. These actors are have hugely different perspectives and priorities from most of the rest of us. We also need to assume that reality will be more nuanced than an organized public demonstration or a platoon of police shutting the meeting down. Problems are likely to be more individual and more quiet. That does not make the problems less or more serious. Just serious. What we have in front of us is some pretty plain language: contents of the Group's activities, visual or audio presentations...contain any defamation against the Government of the People's Republic of China, or show any disrespect to the Chinese culture, or violates any laws of the People's Republic of China or feature any topics regarding human rights or religion ... Hotel reserves the right to terminate the event ... Hotel will claim compensation from the Client Some of the assurances folks have offered are based on conditions not required or covered by this language. For example, this does not refer to, or imply, an organized protest, as some folk have tried to suggest. Let's be very clear: This allows the Hotel to shut the meeting down, according to its interpretation of things -- not ours or the government's -- and to charge the IETF for having done it. Let's also be clear: 1. We often are highly disrespectful. As a group, we really suck at being careful. 2. Technical discussions often must discuss usage policies and, as has been repeatedly noted, some legitimate IETF topics run smack into national privacy and human rights issues. Take this simple fact and match it with our indelicacy and the odds are high that there will be comments that violate multiple terms of the contract. As with others, I cannot fathom the line of logic that says this unique set of contract conditions will be ignored. I also cannot fathom claims that the legitimacy or utility of the IETF depends upon where we hold our meetings. I don't recall seeing that in any of our documents and I don't recall its being discussed over the last 15 years. Over these many discussions about venue, concerns about venues have /always/ reduced down to preferences of the host, rather than utility or legitimacy of the IETF. The fact that some folk are now casting things in terms of utility or legitimacy -- or in terms of the IETF's being some sort of ambassador of the Internet -- appears to be spontaneously generated. That reduces both their utility and their legitimacy. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
That I can pretty much guarantee, plus a whole bunch of tasty alternatives to cookies and of course many variants of tea. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Wed, 23 Sep 2009, Wes Hardaker wrote: > > On Wed, 23 Sep 2009 14:48:36 -0400, Michael StJohns > > said: > > MS> If your answer is - "because there's some benefit to the IETF" - I > MS> would then ask what else should we be willing to give up for other > MS> benefits and where should we draw the line? > > If we give up our normal level of free speech then we should expect darn > nice cookies in trade! > -- > Wes Hardaker > Cobham Analytic Solutions > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Important Information about IETF 76 Meeting Registration
the japanese equivalent of the OMROM V600-D23P71 --bill On Wed, Sep 23, 2009 at 09:16:37AM -0700, Ole Jacobsen wrote: > I have asked Osamu and Kato to answer. Stay tuned. > > Ole > > > Ole J. Jacobsen > Editor and Publisher, The Internet Protocol Journal > Cisco Systems > Tel: +1 408-527-8972 Mobile: +1 415-370-4628 > E-mail: o...@cisco.com URL: http://www.cisco.com/ipj > > > > On Wed, 23 Sep 2009, Samuel Weiler wrote: > > > I'm interested in the answers to the questions asked by EKR a couple of > > weeks > > ago... > > > > I'd also like to know which frequency band these tags use: are these 125kHz > > or > > 13.56MHz tags? > > > > -- Sam > > > > On Mon, 7 Sep 2009, Eric Rescorla wrote: > > > > > Alexa, > > > > > > Can you clarify what, if any, the security properties of this system > > > are: > > > > > > In particular: > > > > > > 1. Will the RFID tag in question respond to any reader or just those > > > controlled by the secretariat? > > > 2. Is the information on the tag in the clear or encrypted? > > > > > > My general experience with RFID systems suggests that the answer to > > > these questions is likely to be "yes" and "in the clear", but I'd > > > certainly be pleasantly surprised to hear otherwise. > > > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 standard?
Olivier MJ Crepin-Leblond wrote: > Being some kind of IPv6 > "evangelist", I'll admit it, I do need to gain a feeling of points of > view from people who are in the know, and the range of replies in this > short thread has been interesting indeed. Given that IPv4 address space can be extended with port numbers still preserving the end to end transparency, why do you insist on IPv6? > With such problems being encountered with dual stack, would it make > sense to deprecating IPv4 standards ASAP in order to shorten the time > for use of dual stack and this shorten the likelyhood of consumers being > turned off IPv6? Not at all. Instead, deprecating IPv6 makes sense. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 standard?
Just for the record, I continue to object to / humbly disagree with Mssr. Ohta's position. While the case for "transparent NAT" may be valid, I believe IPv6 to also be a valid and valuable technology for the continued growth and expansion of the Internet. (Even eliding the amount of change required to implement "e2e NAT", and how this comes close to the amount of work (in many regards) as deploying IPv6, w/o all of the same capabilities.) And FWIW, I also continue to believe 'the world' agrees with IPv6 being 'the solution' ... Based not upon current traffic volumes (of course), but rather the number of deployments I know are happening now'ish (6 large carriers that I have personal experience with in North America ... Including a few of the largest 'residential ISPs' in the US. This reinforces my belief that not only is IPv6 in little to no danger of being deprecated, but that in fact the opposite is (yes, finally) happening. And not to mention (ahem) 'little content providers', like Google ... Or the US federal govt's re-invigorated push towards IPv6 ... ) /TJ Sent from my Verizon Wireless BlackBerry -Original Message- From: Masataka Ohta Date: Thu, 24 Sep 2009 08:52:43 To: Olivier MJ Crepin-Leblond Cc: 'IETF Discussion' Subject: Re: IPv6 standard? Olivier MJ Crepin-Leblond wrote: > Being some kind of IPv6 > "evangelist", I'll admit it, I do need to gain a feeling of points of > view from people who are in the know, and the range of replies in this > short thread has been interesting indeed. Given that IPv4 address space can be extended with port numbers still preserving the end to end transparency, why do you insist on IPv6? > With such problems being encountered with dual stack, would it make > sense to deprecating IPv4 standards ASAP in order to shorten the time > for use of dual stack and this shorten the likelyhood of consumers being > turned off IPv6? Not at all. Instead, deprecating IPv6 makes sense. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 standard?
On 2009-09-23 21:05, Olivier MJ Crepin-Leblond wrote: ... > > Is a dual stack IPv4-IPv6 likely to be more unstable than pure IPv4 or > pure IPv6? Apart from the software engineering principle that more of almost anything is less reliable, there is a specific problem that if your computer believes it has IPv6 connectivity, but actually doesn't, *and* if your DNS service returns records, then you will see long delays in connecting to dual-stack servers while the application tries IPv6, times out, and finally tries IPv4. But of course some sort of flag waving exercise such as deprecating RFC 791 would have no effect on this in the real world. Running out of IPv4 addresses, and discovering that both nested NAT and port-based address sharing are horrible, will do it for us. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meetingof the IETF
IAOC, I'm trying to understand what is political speech in China. The Geopriv WG deals with protecting users' location privacy. The policies of more than one country have come up in geopriv meetings in very derogatory terms. There have been very derogatory comments made by people about the US's wiretap policy. Unless someone can point me at specifics of what is or is not OK, I would find this very concerning. We also regularly discuss issues around Taiwan/China, cryptography, wiretap, DNS root server location, reverse engineering, and so on. Clearly most the people involved with IETF would never want to break the laws of the country they are visiting but the question is do we actually understand the laws and what impact do they have on our technical work? To help us make informed decision about whether these terms are issues or not: 1) What is political speech in China? And can we explain that to IETF participants well enough that they know what is OK and what is not. 2) Are there any special rules about publishing and broadcasting? I note that the IETF, unlike most other groups having meetings, broadcasts the meetings live over the internet, which will be both publishing the material and exporting it outside of the PRC. 3) Are there any rules around discussion, publication, or export of of cryptography algorithms and technology? publishing weaknesses of national crypto algorithms? 4) Many of our participants use communications products (like jabber clients) that they helped develop and include strong cryptography. Do they need permission to use these in China? 5) When discussing what I think of as technical issues, many participants regularly treat Taiwan and PRC as two different countries and currently recognize both of them as separate countries in their own right. I'd actually venture a guess that there is strong IETF consensus they should be treated this way. Could any discussions like this be viewed as political speech? What are the rules on this? 6) It is not core to IETF work but some of us do some interop of running code for IETF protocols under development sometimes at IETF. This would be about the right timing for running P2PSIP code, but that requires us to to run a local CA. Is any special permission needed to run a CA in China? 7) Would we be OK running a BOF on techniques for firewall advancement in general and in particular on getting around any firewalls China runs? [Seriously, you know someone will propose this BOF, the questions is could we run it or not?] 8) Given the Chairs for WG set the agendas and such, I am assuming that a reasonable person would consider all the presentation done by presenters at the front of the room to be things that are under control of the client. Is this the assumption the IAOC is working under too? 9) What is the IETF's potential liability here. If the meeting was canceled on Monday, everyone checked out of hotels early and paid a one day change fee, would the IETF be responsible for the hotel's loss of revenue for the Wednesday through Friday nights? 10) If the meeting is canceled, will the IETF be reimbursing the registration fees? 11) Given the IETF would be depending on the actions of the participants of the meeting to meet the contract, it would seem very prudent to me to make sure that each participant agreed to this. Will you be asking each participant to sign an agreement agreeing to these terms? 12) Do you all feel like you need a beer yet? I'm trying to get to the bottom about what is legal and what is not in the PRC. Ignorance is not an excuse for the law in any country and when I don't know if something is legal or not, I don't do it. Right now I am looking for input from knowledgeable people on these questions. I imagine the IAOC has looked into many of these and would appreciate understanding what you have found. Thanks, Cullen On Sep 18, 2009, at 9:42 AM, Marshall Eubanks wrote: Greetings; We have received numerous suggestions and requests for an IETF meeting in China and the IAOC has been working on a potential China meeting for several years. We are now close to making a decision on a potential upcoming meeting in China. However, the following issue has arisen and we would appreciate your feedback. The Chinese government has imposed a rule on all conferences held since 2008 regarding political speech. A fundamental law in China requires that one not criticize the government. Practically, this has reference to public political statements or protest marches, which are not the IETF's custom. The government, which is a party to the issue, requires that people who attend conferences in China (the IETF being but one example) not engage in political speech during their tour in China. We consider this to be acceptable, on the basis that the IETF intends to abide by the laws of whatever nations it visits and
Re: Request for community guidance on issue concerning a future meeting of the IETF
On Sep 18, 2009, at 1:50 PM, Alissa Cooper wrote: On Sep 18, 2009, at 11:42 AM, Marshall Eubanks wrote: "Should the contents of the Group's activities, visual or audio presentations at the conference,or printed materials used at the conference (which are within the control of the Client) contain any defamation against the Government of the People's Republic of China, or show any disrespect to the Chinese culture, or violates any laws of the People's Republic of China or feature any topics regarding human rights or religion without prior approval from the Government of the People's Republic of China, the Hotel reserves the right to terminate the event on the spot and/or ask the person(s) who initiates or participates in any or all of the above action to leave the hotel premises immediately. We will definitely talk about privacy in GEOPRIV. One interpretation of the above provision would lead me to conclude that at the very least the GEOPRIV group would have to get some of its presentation materials approved by the government in advance. What is the approval process and how long should we expect it to take? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China venue survey
On Sep 23, 2009, at 9:26 AM, Ole Jacobsen wrote: On Wed, 23 Sep 2009, Ben Campbell wrote: Concrete example: Would a presentation on how tor was used to bypass state controls on news during the recent election protests in Iran be acceptable under the terms of the agreement? That would sound like a perfectly appropriate and timely plenary presentation. And it seems to me to violate the plain language of the agreement concerning "human rights". I am going to assume that such a presentation would be largerly technical, a case study with some political overtones, but technical nonetheless. I would not expect this to get you in trouble, no. Now, if you were to call the China Daily in advance and announce that you intented to reveal (new) methods for circumventing state laws and you declared this an open BOF where members of the public were invited to come and listen to your (I am assuming) perfect Mandarin, then I can imagine you would politely be asked to refrain from this activity. I've seen plenary presentations mentioned in the local news before, both before and after the fact. Our plenary agendas are usually published in advance. And we _broadcast_ them across the entire internet. I am sure we can dream up other scenarioes, but at the risk of repeating myself: in the 68 meetings of the IETF that I have attended, I've never observed activity that would cause concern in the context that we are discussing. Okay, let's dream up one: Let's assume it is largely technical, but has a section touching on the larger human contexts that our technologies effect. Further, assume it takes an explicit position that technological facilitation of human rights is a Good Thing, and that freedom of speech is a "basic human right." Heck, lets even assume it contains anecdotes of individuals who have been punished for speech over the internet, and a list of governments known for censoring speech over the internet, all to reinforce the presenter's opinion that such technologies should be high priorities for the IETF. And for the cherry on top: Assume the presenter is a well known international human rights advocate. So, Do you think _that_ would get us in trouble? Would it be appropriate at some other venue? My biggest concern is not that the authorities or even the hotel will shut us down. It's the chilling effect of self-censorship that others have mentioned. Ole ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
Pete Resnick wrote: And I'll also note again that this contract is between the hotel and the host. The IAOC contract with either should explicitly include words indicating that the discussion of technical topics that touch on human rights issues are excluded from this clause. Pete, Simply crossing off the problematic text is an approach that is clean and simple, and returns the burden to the hotel. Nevermind that some or all of the text is dictated by law. Your suggested re-wording, however, is twice problematic. First, it tries to guess what is acceptable to the hotel and government. The second is that it tries to guess what is acceptable to the IETF community. Guessing the former is reasonable when you really are in a negotiation and have some sense of the other side. This ain't one of those cases. And as a member of the IETF community, I think your proffered text constrains things too far. "Discussion of technical topics" is not likely to cover discussion of the national and other policies that might affect or motivate use of the technology. Yet that, for example, is entirely plausible material for some IETF groups. Of course, there is also the inherent humor of trying to contractually constrain speech by the entire participating IETF community, given our unruly history... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
On Wed, Sep 23, 2009 at 03:23:57PM -0400, Marshall Eubanks wrote: > > As far as I know, you are not a lawyer (please correct me if I am > wrong). I am not a lawyer. Ole is not a lawyer. What use is any of us > doing this analysis ? I might as well ask the IETF Counsel to produce a > technical analysis of LISP-ALT. I don't think that this will get us > anywhere. I may not be a lawyer, but if there is a contract which says, "any topics regarding human rights" must require prior approval of the Chinese government, the plain reading of the contract is pretty clear, and if lawyer told me, nah you don't have to worry about the obvious wording of the contract, it's just normal boilerplate, I think I would be right to ask for a second (or third opinion). I understand that it is very hard for a lawyer to tell us whether or not there is a guarantee that we will be "safe", but if there is something that is clear on the face that might be "unsafe", I think it takes a fairly large amount of handwaving to say, "that's not something you need to worry about in the contract". In fact, lawyers are usually telling us the opposite! Given that a number of people have already observed that comments of the form of how our protocols can be used to ensure human rights are certainly not unknown within the IETF, and it's not even clear such a comment would not be considered inappropriate, and there's a clear cause that seems to indicate that we should not even *mention* anything related to human rights without the prior approval of the Chinese government, it's clear that there will be some restriction on discussions that would otherwise legitimately take place at other IETF venues. Against that, we weigh the argument that the IETF would somehow become "irrelevant" if it doesn't meet in China. Personally, I have trouble buying that. Perhaps the cost of restricting legitimate discussions about how protocols might be used when it involves human rights or freedom is slight (although some might disagree with that; some might view this as a principle that's not worth compromising); but it's not clear the benefits of going to China are that great, either. > A long time ago, I learned that the letter of legal agreements is in > many cases less important than the intent of the parties. Maybe, but at the end of the day, "the law is the law". The intent of the host and hotel may be good, but good intentions have never overruled law in a civil society which is governed by the rule of law. And the argument for why the statement *must* be present in the contract is that it is required by Chinese national law. I'm not sure which is worse, the argument that we don't need to worry about the law (thus implying that maybe China isn't actually a society where the rule of law is important), or that the law actually *does* impose these restrictions and is for real. My two cents, - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
