Stephen, I've no idea what you think you mean when you say 'moving beyond mandatory to implement'. My take is that encryption should never be mandatory to implement. Your unspoken assumption seems that it is first always mandated, and then lifted under certain special circumstances. That would be the wrong way around. >> Increasing the cost to the "attacker" means increasing the costs to >> the implementer and to the user, and to the designers, far more. > > "far more"? I disagree. The high cost of using crypto was a fine > argument to make 20 years ago, but for almost all systems that's > no longer the case. I did not discuss processing cost, though that's also relevant, particularly for low-end systems. My concern is that the cost to designers of trying to design transport protocols becomes unacceptably high, as any attempt to design a transport protocol becomes defending against the design of what has just become a security protocol. I view the failure of DTNRG work - where tailoring for the DTN scenario was dropped in favour of emphasising security work, and problems with the protocol would be fixed by the security framework, but weren't - as an example of this. And where the IRTF leads, the IETF follows. If security wonks understood transport mechanisms, this might be less of an issue. But as DTNRG ignored checksums and the end-to-end principle for years, that seems unlikely. Security has a cost, debating with security aficionados has a cost, defending designs against security unneeded for use has a cost. I believe that TCP and http are only widespread because security was not part of their remits. >> 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. > > I think that's nonsense fwiw. Of course you do. But you wrote the ridiculously complex RFC6257, and focusing on that sidelined transport work in DTNRG in the process - and a delay-tolerant network is ultimately all about the transport. That nicely demonstrates my fears. > I suspect Lloyd and myself > won't have a meeting of the minds on the topic though;-) Damn right. Lloyd Wood http://sat-net.com/L.Wood/dtn/bundle.html ________________________________________ From: Stephen Farrell [stephen.farrell@xxxxxxxxx] Sent: 06 December 2013 11:57 To: Wood L Dr (Electronic Eng); hannes.tschofenig@xxxxxxx Cc: ietf@xxxxxxxx Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: perens-perpass-appropriate-response-01 Hi Lloyd, (dropping httpbis, Mark asked to reduce their noise level yesterday) On 12/06/2013 06:42 AM, l.wood@xxxxxxxxxxxx wrote: > 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. That is a good discussion to have, but isn't necessary or relevant for this draft, which itself doesn't specify nor mandate any particular mitigations. I think you're attacking a wrong target. > 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? There is a difference - with DRM, the user is considered the adversary, in this case the adversary (in protocol terms) is often a third party. But yes, there are pervasive monitoring situations where the adversary might be the service provider, but those are to some degree outside the IETF's remit for now, except where we have good e2e security options. Unfortunately, in many cases we do not yet have good enough e2e security options that can be deployed at Internet scale to handle such cases. But we should continue to work at that. A case where we can provide e2e would be XMPP, where OTR is a good proof that you can provide some e2e security and the XMPP WG are working away at a standards track e2e solution. (And separately some folks are writing up an I-D on OTR I think.) We are not however going to stop sending email just because neither S/MIME nor PGP are good enough. And this draft won't mean that anyone making such an argument (e.g. that we should all use S/MIME all the time) will be able to use the resulting BCP to force their wishes on an unwilling world. What this BCP (when published) will do is ensure that someone who has a good technical option doesn't have to re-litigate the argument that pervasive monitoring is an attack that we should mitigate. > 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. In the context of a discussion of whether the IETF should move beyond mandatory-to-implement, (MTI) I would argue each of the above. But, that's not this discussion. > 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. We are quite properly reacting to newly presented and relevant facts. Even if we don't have a full picture of all the facts, its unquestionably the case that we have enough real information to justify taking action. > 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) BCPs only get updated after IETF last calls. > as a club to justify encryption in all transport protocols. > This does not bode well. Fear not! Again, if your fear is of "more than MTI" then that is not part of this draft but is a separate discussion. > Increasing the cost to the "attacker" means increasing the costs to > the implementer and to the user, and to the designers, far more. "far more"? I disagree. The high cost of using crypto was a fine argument to make 20 years ago, but for almost all systems that's no longer the case. And if you look at the work e.g. Tero did for IPsec with no certificate handling, (which I think is being documented in lwig) its quite possible to do the crypto in very tiny devices. Doing key management securely is harder in such such environments though that is true, and would be something that relevant working groups would take into account. > 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. I think that's nonsense fwiw. I suspect Lloyd and myself won't have a meeting of the minds on the topic though;-) S. > 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 >