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