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(_dot_)arkko(_at_)piuha(_dot_)net]
Sent: 10 December 2013 12:31
To: Wood L Dr (Electronic Eng)
Cc: hannes(_dot_)tschofenig(_at_)gmx(_dot_)net;
stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie; ietf(_at_)ietf(_dot_)org
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