On 12/12/2013 01:56 AM, Bjoern Hoehrmann wrote: > I am not sure what to make of your comments here. Perhaps an example > might help, http://edition.cnn.com/2010/CRIME/12/08/wikileaks.students/ > > U.S. agencies have warned some employees that reading the classified > State Department documents released by WikiLeaks puts them at risk of > losing their jobs. But what about students considering jobs with the > federal government? Do they jeopardize their chances by reading > WikiLeaks? > > If surveillance is pervasive, then students must assume someone will > know which sites they visit and assume there will be repercussions. So > they are forced into a constant state of fear where they need to care- > fully consider, say, which headlines on a newspaper website they click. > > If your draft is not about removing this fear, then I do not know what > it might be about. If it is, then it would seem to call for "ubiquitous > confidentiality" unless you are making a very fine point. WRT the fear - what Brian said. He put it better than I would have. As to the question of "what's it about that's not ubiquitous confidentiality": There are many other techniques that will be relevant in the end I'd say. For example, over time, I'd hope that we end up with fewer protocols that provide uncontrollable opportunities for tracking. That will require application protocol design considerations that don't involve crypto. Some protocol designers will I would hope require fewer long term identifiers to be visible to many entities, for example some values only needed hop-by-hop could change so as not to be the same end-to-end. I'm thinking of how the X-Forwarded-For that became the standards track HTTP Forwarded header field could have been done better had privacy been a serious requirement. Maybe some hash function would have been a part of a better solution there, or maybe obfuscation, but confidentiality would not have been relevant in doing that work. For DNS, we've seen a proposal to not send the full QNAME in all queries as those are sent up towards the root. No crypto, since it just involves sending less stuff, but a possibly nice (though not problem-free) mitigation. Perhaps CGAs will become more popular - those do involve crypto but no confidentiality. Speculating - perhaps people will find better ways to manage networks without recording (bytes from) every packet or flow. If sampling and statistical methods can meet the requirements without being so close to pervasive monitoring then that might make for a privacy-friendly IPFIX profile for example. Yes, confidentiality provided via crypto will be a part of some protocol design work. But far from all of it. And for many protocol designers, if they can easily layer on top of TLS or IPsec then that'll be the right choice and those protocol designers won't be doing crypto protocol design. (Thankfully:-) Certificate Transparency is another potential part of some mitigations for pervasive monitoring, and while that might be a user of a confidentiality service, it doesn't provide one. And so on. And there will be cases where we've no good mitigations to offer: I've no idea how one might run DHCP with crypto based confidentiality, nor even practical e2e email security as I mentioned before. There'll be loads of protocols where we just don't have a workable confidentiality service and we'll live with that. So yes, we've a wait on our hands before we get perfection. Please don't hold your breath:-) And what the 106-email-but-inconclusive "https at ietf.org" discussion does show up is that there are still some arguments for making some information available in clear. (I'm not saying what I think is the right conclusion of that argument.) This draft doesn't claim to judge the best outcome for that discussion, it just says that the discussion needs to be given proper (and not perfunctory) consideration. Its sort of optimistic in that respect and assumes that if the IETF do properly consider something then we tend to have a hard time denying e.g. laws of physics:-) I guess the biggest stick embedded in the draft is that if some WG demonstrably don't tackle the issue where some obvious mitigation exists, then that WG should experience unhappiness. And even with all that, this draft does not actually call for any security mechanism to be more-than-MTI, where MTI means mandatory to implement which has been the IETF's consensus position on strong security mechanisms for over a decade [1]. So there's no process innovation here and confidentiality is just one tool in a toolbox that I hope we start filling up some more. And I figure this BCP can help there to really get better technical outcomes, and without being at all onerous. I don't think its quite a no-brainer, but for anyone who's thought the issues through, it should appear to be a no-brainer. Hence my question as to the (ir)relevance of John's comment. But having said all that, would I personally like it if the IETF did reach a consensus position that everything possible MUST be encrypted by default? I probably would. But that's a separate day's work and is not called for by this draft no matter how many times people mis-represent the draft as saying that it does. Hope that helps, S. [1] http://tools.ietf.org/html/rfc3365 >