On 12/08/2013 05:56 AM, l.wood@xxxxxxxxxxxx wrote: > 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. MTI security is what's called for by BCP 61. Sometimes the MTI security for a protocol will involve confidentiality, other times (e.g. routing protocols) it has tended not to. So your "take" is at odds with long standing IETF BCPs. > 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 also meant that. Arguing that we don't know how to engineer this is also a fine 1990's era argument. > 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. Your and my descriptions of about 90% of things related to DTN seem to be at odds. And that's the case here too. S. > > 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 >> >