Re: [saag] should we revise rfc 3365?

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

Hi Peter, 

when we develop protocols in the IETF they are meant to be used for the
Internet and you have to make the design according to the toughest
requirements and not the simplest. In many cases, protocol designers do
not really know how exactly their protocols will be used and so you
cannot just make some simplifying assumptions. 

For smart objects (you call them low-power devices) the approach is
still to provide security or otherwise not connect them to the Internet.


I think that this approach of providing a version of the protocol that
is completely insecure (in case we have a really convenient deployment
environment is really dangerous) as the usage of the protocol can
quickly be used in different contexts and then the user is in trouble. 

So, I think you are on the wrong track. 

Ciao
Hannes

> -----Original Message-----
> From: ext Peter Gutmann [mailto:[e-mail]]
> Sent: Saturday, May 26, 2012 3:18 PM
> To: Tschofenig, Hannes (NSN - FI/Espoo); [e-mail];
> [e-mail]
> Subject: Re: [saag] should we revise rfc 3365?
> 
> "Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>
writes:
> 
> >I see this argument quite often that we should not impose strong
> security
> >requirements on protocols because there may be this use case where no
> >security is needed.
> >
> >I am wondering what protocols you are thinking about that need no
> security.
> 
> It's not protocols that may or may not require security, it's uses of
> protocols.  Something on an internal LAN probably doesn't require it.
> Something on a CAN (where 'C' is for 'controller') almost certainly
> doesn't
> require it.  Low-power embedded devices (where the options are no-so-
> strong
> security or none at all) don't require it.  Systems where throughput
> and/or
> low latency are critical and you "secure" them by running a cable from
> box A
> to box B don't need it.  And so on and so on.
> 
> It's fair enough to say "if you require strong security then you can
do
> X",
> but saying "the protocol MUST include X" is inappropriate.
> 
> Peter.