----- Original Message ----- From: "Hannes Tschofenig" <hannes.tschofenig@xxxxxxx> To: <l.wood@xxxxxxxxxxxx>; <stephen.farrell@xxxxxxxxx> Cc: <ietf@xxxxxxxx> Sent: Sunday, December 08, 2013 10:07 PM > 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. <tp> Lest it be thought that the same applies to me, let it be clear that I am a MASSIVE fan of security, security being authentication, authentication and authentication (with integrity not far behind, and encryption, well you know my views on that). It is phishing and its derivatives that I see as most damaging to the general users of the Internet, such as I; and every time I hear the media say, 'look for the padlock on the screen' I think 'another bunches of lambs being led to the slaughter'. And I think that the IETF is not doing what it should when it does not pay more attention to that. What did we do with "draft-hartman-webauth-phishing-05.txt"? Tom Petch > 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 > >