Subject: Re: [saag] should we revise rfc 3365?

From: Joe Touch <[email-masked]>
Date: Wed, 06 Jun 2012 17:34:48 -0700

FYI - see attached notice for the port-use doc in TSVWG.

Joe

On 5/23/2012 5:56 PM, Joe Touch wrote:
>
>
> On 5/23/2012 4:51 PM, Mouse wrote:
>>> Short version: go read [RFC 3365] and say if you think it needs an
>>> update.
>>
>> Yes, but I believe it's not one you're willing to accept.
>>
>>> "MUST implement strong security in all protocols"
>
> To open a can of worms, this would also be a good doc in which to
> discuss the need for secure ports, and whether (or not) to ever assign
> meaning to the difference between system and user ports...
>
> I was hoping to potentially open those discussions on TSVWG regarding
> the user-ports draft, but it might also be relevant here. I'm not sure
> if either will come to conclusion, but a round of discussion seems in
> order.
>
> Joe

Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-port-use-00.txt
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Date: Thu, 31 May 2012 23:34:17 -0700
List-Id: Transport Area Working Group <tsvwg.ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title           : Recommendations for Transport Port Uses
	Author(s)       : Joe Touch
	Filename        : draft-ietf-tsvwg-port-use-00.txt
	Pages           : 11
	Date            : 2012-05-30

   This document provides recommendations to application and service
   designers on how to use the transport protocol port number space to
   help in its preservation. **NOTE THAT THIS CURRENT VERSION IS
   LARGELY AN OUTLINE OF ISSUES**.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-use-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-port-use-00.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Jun 2012 20:49:35 -0500

On Tue, May 29, 2012 at 11:13 AM, Mouse <[email-masked]> wrote:
>>> 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
--