John, In a number of places below, you appear to make hugely misleading and inaccurate characterisations of the text of the draft, to the point where I think you seem to be spreading FUD. Can you please explain how I'm wrong in that conclusion? Ideally via reference to the actual text, and justification for how you make the gigantic leaps from that text to your vastly overstated mischaracterisations below. Or, since I'll separately address what I guess might be the potential concerns behind the FUD that is here, you can if you like ignore this message and just respond to a mail I'll send later today. On 12/31/2013 08:48 PM, John C Klensin wrote: > That principle is that I do not believe the IETF should be > making statements supporting any particular religion or set of > religious principles or, as we might say on this side of the > pond, expressing strong support for motherhood and apple pie. I'm sorry but I think the term religion above is purely being used as a pejorative, and wrongly in this case. Or maybe you can justify the use of the term via at least some reference to the actual text of the draft? > Statements of general concern are ok, but apparent commitments > to action without specifics seem to me to be ill-advised. Disagree. Ted Lemon put it well. This draft represents the high-order bit but there's more work on going and to be started. > To > me, your document, and much of the discussion, reflects the > reason why that principle is important: No matter what > assurances are made to the contrary, we've seen example after > example, general guideline after general guideline, turned into > rigid rules during or after Last Call on particular documents > because some AD decides that a document that doesn't match his > (usually -- I think we've yet to have a really abusive, > testosterone-poisoned, woman AD) ideas of how things should work > and should therefore be blocked until the authors or WG either > conform to whatever "requirement" supports his conclusion or > produce an overwhelming proof that should not be necessary. I think that's spreading FUD to be honest. I can't see how its anything else. And again, as Ted said, if some AD wanted to be a pain in that way, there's plenty of ammunition available today for that (see the 2119 references in 3552 for an example of such ammunition that is not used). Indeed 3552 is a fine example of why we do not want BCPs that contain too much detail - that detail will go out of date or not apply to new situations and overall adds to the potential ammunition that a misguided AD could use to badly affect ongoing work. Any such detailed guidance should be based on reality and not be theoretical IMO and so should emerge from what we find can actually be deployed. This BCP will not change the potential for any AD to abuse the IETF. Not a whit. And it really doesn't matter what happened 10 years ago or whenever you care to pick. > I think much of that case had been made by others and was > writing my note in that context (see below). But maybe not. > > So, at the risk of repeating something others have said, I don't > want to see a Last Call (or, worse, post-Last Call) debate about > whether the authors of a document that isn't seen to be secure > enough against persuasive surveillance has done everything that > might be possible to mitigate that risk. "Everything that might be possible" is a serious mis-reading of the draft and *nothing like* what's stated in the draft. I can't see how you get that from the text. If there is text there that could really be mis-read that badly then please point at it so we can fix it. > I'm in favor of > mitigation being considered an important consideration, just as > I'm in favor of privacy considerations more generally being > considered important considerations. But I'm also in favor of > congestion control, operational reasonableness, security > considerations that don't directly relate to privacy including > strong authentication when it is warranted, > internationalization, and a slew of other things that I think we > should be considering when protocols are adopted... and > considered without the impediment of someone saying "well, the > IETF adopted a formal statement that says 'Particular issue XYZ > should be mitigated where possible' so that consideration should > dominate the others." "Dominate the others" is another serious mis-reading. Again, please point at the text that has so confused you. (To be honest, I don't think its there so am mystified that you can get this meaning from the current text.) > > My problem with going in that direction interacts with your > draft in many ways even though I'm in agreement about the > high-level issue. As a description of an issue, I think it is > fine. When you describe and rely on the consensus reached at > IETF 88, I start having objections because I think the questions > were stated in a way (and context) that made disagreement with > them, or examination of the implications and details, nearly > impossible. You expected to examine all the implications and details in a room with ~1000 people? In any case, this draft does not, and should not, try to examine all the implications since we don't know them all yet. Nonetheless if we don't have this BCP then we will have to re-litgate the overall discussion many times, which will (I predict) effectively prevent us from making progress on the more substantive issues with protocols. That is one harm in your position and those of others who want to wait and do nothing until everything is "clear." > > To take an example I hope is not taken as a proposal, the > security of SMTP against in-transit interception and monitoring > of messages could a considerably improved by eliminating > relaying (i.e., the application-level store and forward design > of the protocol). That would have a number of profoundly bad > effects, at least IMO, but it would enable some rather simple > methods of mitigating the threat that are of arguable or complex > utility if relaying is permitted. If the Apps ADs ever get > around to getting back to me about a months-old request to > discuss practical methods of moving RFCs 5321 and 5322 forward > to Internet Standard, I don't think it is reasonable to > legitimize an attempt to impose a requirement that starts with > "RFCnnnn says that monitoring threats should be mitigated where > possible, so we have to return to first principles and debate > whether SMTP should have relaying" when, without such a > statement, we'd be able to say "widely deployed, useful, and > working that way for a few decades, we just don't need to have > that discussion about the base protocols". I have no idea how that is relevant. Are you suggesting that this BCP will suddenly mean that bad ideas get airtime when they previously would have been discarded? That seems silly. > >>From that point of view, when you say "Those developing IETF > specifications need to be able to describe..." [Section 2, > paragraph 4], I get the chills because, despite the mitigating > (sic) second sentence, the third, and the subjectiveness of "a > good answer", allows someone with the inclination to block > almost any application-layer protocol until it is encumbered > sufficiently with privacy decorations to make it unattractive > and unlikely to be adopted in practice. I would like the 5th > paragraph of Section 2, except that I don't look forward to the > pain I believe this document is likely to cause as that > "appropriate balance" emerges and is visited and re-visited. See above. I think that's a frankly weird mis-reading of the text which is pretty clear that pervasive monitoring is to be addressed in the same way as any other vulnerability. > > Now to put my earlier note and your questions about it and its > relevance in context... > > > --On Wednesday, December 11, 2013 21:19 +0000 Stephen Farrell > <stephen.farrell@xxxxxxxxx> wrote: > >> I've a question about the relevance of your comment >> John: >> >> On 12/11/2013 08:53 PM, John C Klensin wrote: >>> if encryption >>> were pervasive >> >> The draft in question does not call for that. It calls >> for proper consideration of the pervasive monitoring >> attack and work to mitigate that. > >> Use of encryption for confidentiality will be a relevant >> mitigation for various protocols, but to comment as if >> this draft called for ubiquitous confidentiality seems >> very odd if one has read the draft. > > Oh, I had read the draft, and read the newer version this week. > What I tried to do was to think about making the broad and > general statements in the draft actionable and what that would > mean. Remembering that I work at the application layer where > almost all data that users might consider sensitive occurs > directly rather than by side-effect, our toolkit is rather > limited. At least at the application level, if there are ways > with most protocols to significantly mitigate pervasive > surveillance that do not replace it with ubiquitous > confidentiality (or with pervasive encryption, which is what I > actually said) and that fall within the scope of IETF protocols, > I don't know what they might be. Eh... not sending PII when its not needed in a protocol? I believe I answered that last month. [1] What's not clear about that answer? [1] http://www.ietf.org/mail-archive/web/ietf/current/msg84918.html > > Actually, I do, but I think the IETF would find them > unpalatable, and that brings me back to my concern about this > document and its apparent attempt (whether you intended it or > not) to move mitigation of pervasive surveillance to the front > of the tradeoff line. That is not an accurate description of the text. You are radically mis-interpreting what it says. There is nothing in the draft that moves anything to front of any line. > For example, effective surveillance of > traffic content by monitoring of Internet links would become > considerably more difficult if we (pervasively) went back to > routing at the packet (or datagram) level and optimized our > routing algorithms to prefer diverse paths within a stream or > flow. At least as I understand it, that would largely eliminate > the use of MPLS Saying that this BCP would eliminate MPLS approaches being purely FUD. > and would slow things down overall unless ISPs > started engineering their networks for more path diversity > between any two endpoints (presumably increasing costs for the > amount of traffic handled). But it would make interception of > a single flow for surveillance purposes a lot more unpleasant > and costly for the monitoring body without requiring encryption. > There are other examples but, as far as I know, they are equally > unattractive... unless frustrating pervasive surveillance > becomes out primary objective (and, as you point out in the last > paragraph of Section 2, that of others). "Primary objective" bears no resemblance to the draft at all. >> John - can you say what part of the draft caused you to >> incorrectly conclude that "pervasive encryption" (whatever >> that means) is even being discussed never mind recommended? > > I hope that the above responds to that question, whether we > agree about the conclusions or not. The above does not quote any text and IMO hugely mis-states what is in the draft. I have no clue how you could interpret the text as you claim to have above. S > > best regards and best wishes for the new year, > john > > > >