[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-saag
Subject:    Re: [saag] should we revise rfc 3365?
From:       Nico Williams <nico () cryptonector ! com>
Date:       2012-06-07 1:49:35
Message-ID: CAK3OfOjsmuBoBS2ztUh1DNjy+785W5BGsJSUMHvErw6PkXdFeA () mail ! gmail ! com
[Download RAW message or body]

On Tue, May 29, 2012 at 11:13 AM, Mouse <mouse@rodents-montreal.org> wrote:
>>>> "MUST implement strong security in all protocols"
>>> I believe this is too dogmatic a position, and will simply lead to
>>> IETF process being ignored in [some cases].
>> So how would you phrase it so that we do get security mechanisms
>> defined in most all cases but not when they're really really not
>> needed (or fictional)?
>
> I don't think that can be done by drawing a hard line in the sand, as
> 3365 tries to do, regardless of where that line is drawn.  Whether
> strong security is appropriate is a judgement call, as is how much
> security constitutes `strong' for a particular purpose.  And judgement
> calls have this annoying property that they require, well, judgement,
> that they can't be made by unambiguous algorithms.
>
> It's possible I'm just missing something, but I can't see any way to do
> this that doesn't mean involving real humans.  3365 appears to be
> trying to do it in a way that avoids needing to involve humans;

So let's give guidance.  Something like:

"It should be possible to implement and deploy Internet protocols
securely vis-a-vis the Internet threat model.  Some protocols can have
no security features and still result in deployable security.  For
example, it is possible to use IP without having to deploy IPsec and
yet obtain decent protection -against adversaries per the Internet
threat model- by using TLS or other suitable protocols.  In fact,
quite a few Internet protocols can be deployed with no security
functionality and the resulting systems can still be secure in the
Internet threat model: ARP, IP, UDP, TCP, DHCP, etcetera.
Additionally, low-value services need not require any security
functionality in the protocol.  For some protocols a security option
is desirable, such as in IP (IPsec) and DNS (DNSSEC), for some a
security option would be unwelcome (e.g., UDP, DHCP), while other
protocols absolutely must have security options.  In general
high-value (or potentially high-value) applications require security
options (e.g., HTTP applications)."

IMO security choices generally (but not always) belong in the
application layer, though session security doesn't necessarily (e.g.,
TLS is below the application layer).  Deploying real, end-to-end
security at the IP layer (IPsec) is currently so difficult that it
cannot be scaled to the Internet, while deploying decent security at
the link layer is feasible and desirable but cannot address the
Internet threat model (due to the link layer inherently not being
end-to-end).

Nico
--
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

[prev in list] [next in list] [prev in thread] [next in thread]