Hannes, 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. Transport suffers as a result. Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: Hannes Tschofenig [hannes.tschofenig@xxxxxxx] Sent: 08 December 2013 22:07 To: Wood L Dr (Electronic Eng); stephen.farrell@xxxxxxxxx Cc: ietf@xxxxxxxx Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: perens-perpass-appropriate-response-01 Lloyd, I think we have expressed our positions here. I fear no additional views from my side will change your positions on that topic. You are just not a big fan of security. If I have a wrong impression drop me a note and we do a quick off-list chat. Ciao Hannes On 12/08/2013 09:46 PM, 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. > ...only for standards-track protocols. > > And that document asks 'is encryption a MUST' and sensibly answers 'no' > as far as confidentiality goes. draft-farrell-perpass-attack goes beyond > that to insist on confidentiality everywhere. > > So, your take on MTI seems far far broader than that in BCP 61. > > [..] > >>> 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. > DTNRG (late 2000s, yet still persisting as a group as e.g. the TCP > convergence layer isn't published yet) is a much more recent example > of this. > > >>> 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. > Damn right. > > Lloyd Wood > http://sat-net.com/L.Wood/dtn