Sent from my HTC Touch Pro2 on the Now Network from Sprint®. -----Original Message----- From: John C Klensin <john-ietf@xxxxxxx> Sent: Tuesday, December 31, 2013 12:48 PM To: Stephen Farrell <stephen.farrell@xxxxxxxxx>; Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>; ietf@xxxxxxxx <ietf@xxxxxxxx> Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice Hi. As I indicated in my earlier note, I've been extremely reluctant to be drawn into this very extensive discussion. As a result, I've waited until the last day of the LC period to post this although most of it was written shortly after receiving your note on the 11th (I have reviewed -03 to be sure that anything that changed after my earlier comments has been appropriately reflected(. The reason for my reluctance is rooted in a matter of principle that I believe many of the people who have commented do not share and I don't actually expect to change anyone's mind (especially yours). So I am really not expecting a response to this note -- I just want it on the record that the likely decisions do not reflect anything significantly better than rough consensus. 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. Statements of general concern are ok, but apparent commitments to action without specifics seem to me to be ill-advised. 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 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. 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." 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. 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". >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. 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. 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. 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 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). > 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. best regards and best wishes for the new year, john