To recognise and choose tradeoffs, a broad engineering perspective is needed. My point here is that those with a security focus often simply do not recognise, acknowledge or countenance tradeoffs. The goal of perfecting security does not allow it. An example: Try discussing MD5's use in a reliability context fior error detection with security types. You'll hear that MD5 is insecure, that it's 'broken', that it shouldn't be used, and that's that. Which is why the checksum text now exists in RFC6151, as a careful rejoinder to that. (Yet oddly you don't see anyone complaining about the collisions in CRC32 and the security weaknesses of that.... But knowing about Hamming etc is mere engineering, and beneath notice.) Viewing everything through a security lens doomed DTNRG work, and making security the ultimate arbiter of any protocol, design, as it was in DTNRG, will ultimately destroy any future IETF transport work. The process involved will be simply unsurmountable, the arguments unbearable. Lloyd Wood http://sat-net.com/L.Wood/dtn ________________________________________ From: Jari Arkko [jari.arkko@xxxxxxxxx] Sent: 10 December 2013 12:31 To: Wood L Dr (Electronic Eng) Cc: hannes.tschofenig@xxxxxxx; stephen.farrell@xxxxxxxxx; ietf@xxxxxxxx Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: perens-perpass-appropriate-response-01 > Au contraire. I like security. I recognise the need for security, and am glad it exists. > > I'm just not a big fan of people who demand security where it is not needed, and who prioritise security above all other aspects of protocol design, which are dismissed as unimportant and are neglected as a result. Perhaps it might be easier to discuss this if we all recognised that it is a question of tradeoffs. (But as Phillip correctly noted, the world changes, perceptions changes, new information comes available, and today's tradeoffs may be different from yesterdays.) Jari