My argument is that security (confidentiality and encryption in transmission) should always be _optional_ in a transport protocol. Define a NULL cleartext ciphersuite if you have to, but do make cleartext transmission possible. With the analogy with DRM, encrypting everything didn't work there. Why should it work here? What is gained, apart from a lot of overhead? Allowing encryption to be optional: - increases the chances of base interoperability. - increases the chances of debugging problems in the field. - increases the chance of the protocol even being implemented, or being implemented and used where the threat model does not require confidentiality or encryption as a response. - makes lightweight implementations possible, which can scale down to be fit for purpose. draft-farrell-perpass-attack notes: "the IETF is not equipped to tackle the non-technical aspects of mitigating pervasive surveillance" Well, yes. RFC2804 deliberately passed on the moral position of wiretapping surveillance, while draft-farrell-perpass-attack is appealing to vox populi as its argument. We're not even capable of articulating why pervasive surveillance is bad. We're just reacting to news reports. Frankly, I don't think the IETF is well-equipped to tackle the technical aspects of mitigating pervasive surveillance either. I don't see evidence of that to date. I do not have confidence that the IETF can do good security protocol design together with good transport protocol design. My fear is that the two will be combined into one by using draft-farrell-perpass-attack and its followons (hey, BCPs get updated) as a club to justify encryption in all transport protocols. This does not bode well. Increasing the cost to the "attacker" means increasing the costs to the implementer and to the user, and to the designers, far more. It means increasing the complexity of the specification and implementation. It's complexity beyond what can be handled in committee. draft-farrell-perpass-attack can be considered an attack on IETF transport area work for those reasons. It's going to have more of an effect on the IETF than it will on the NSA. Now, this isn't to say that the IETF shouldn't try to design secured protocols mitigating snooping for users - when there are actual users and use cases, and a threat model that requires consideration of privacy. It should not be an indiscriminate blanket effort. But when an attempt fails to achieve that impossible goal of a secure protocol free from monitoring (and it will fail), having a transport protocol that still useful and workable in the clear once all of the has-been-found-to-be-broken-by-design-before-being-obsoleted security-stuff is stripped away is still an achievement. And that transport can still carry data encrypted at a higher layer. Which is what e.g. TLS is for... Lloyd Wood http://sat-net.com/L.Wood/ sure, you're speaking for security. Who is speaking for transport? ________________________________________ From: Hannes Tschofenig [hannes.tschofenig@xxxxxxx] Sent: 04 December 2013 18:38 To: Wood L Dr (Electronic Eng); ted.lemon@xxxxxxxxxxx Cc: perpass@xxxxxxxx; bruce@xxxxxxxxxx; ietf-http-wg@xxxxxx; ietf@xxxxxxxx Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: perens-perpass-appropriate-response-01 Hi Lloyd, On 12/04/2013 10:55 PM, l.wood@xxxxxxxxxxxx wrote: > I see you ignore the DRM point. I don't understand your DRM point to be honest. It also does not seem to be relevant to this conversation. DRM standards have not been been developed in the IETF either. draft-farrell-perpass-attack-00 does not specific solutions (which it states in the document). If your argument is that security adds complexity to protocols then that's certainly true. The other option would be not to have security in protocols at all to make them "more lightweight". Do you seriously think that this is useful option (even before the NSA revelations)? If your argument is that security problems on the Internet should be solved via legal / regulatory ways then please go ahead an make these proposals. Obviously, the IETF would be the wrong forum to do that. I am sure the European Commission, for example, is interested to listen to your proposals and will immediately issue new proposals for regulation. It would be great if those you think that there are regulatory solutions would in fact then work on those rather than just having technically minded people who push problems around. If your argument is aging cryptographic algorithms require software to be updated then let me tell you that software gets updated even for functionality reasons. Do you think that all the software updates you get for you smart phone apps are only security fixes? There are, however, many software updates that relate to security vulnerabilities. My approach would, however, be to incorporate software update mechanisms into products (which is what pretty everyone in the industry seems to be doing) instead. While this is largely a non-IETF issue it would still be interesting to hear whether you have other suggestions. Your suggestions to do more interoperability testing sounds reasonable to me. I have been involved in interoperability tests myself (and even organized a few). Those tend to have a different focus, namely to provide feedback about whether the implementations interpreted the specs correctly. Penetration testing is what you would typically do to discover security vulnerabilities. We typically don't do those (at least not that I have heard). As such, I would rather seen them as a orthogonal effort (which many in the IETF are involved in already anyway). Are you suggesting that we should also do penetration testing? Please also note that "security" is not a monolithic block, as you can see from RFC 3552. In various discussions with you I got the impression that you dislike security in general. That can hardly be true since I am sure you like some of the security features in there as well. For example, you might find authentication a pretty cool concept to avoid others accessing your email account. Ciao Hannes