Subject: [saag] is one or two ports "more secure"

From: [email-masked]
Date: Tue, 3 Mar 2015 21:56:40 -0000

Hiya,

A protocol that can run over TLS can be allocated two ports
(like HTTP with 80 and 443) or one port and use STARTTLS or
similar.

Ted has a discuss [1] on a document about port number allocations
and asked if the security ADs cared. We think the answer is that
we don't (one can muck up or do ok either way) and we also don't
think that the security area actually has a consensus that one
or two ports is generally "more secure". If you think we're wrong
and there is a clear consensus on then please respond in the next
day or so. If you don't think there's consensus silence is fine.
(As if that'll stop you:-)

Cheers,
S.

PS: We're just asking as it might help folks resolve or work
around some potential repeated arguments on the topic. And we're
not saying whether we actually favour one or two port approaches:-)

[1]
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ballot/#ted-lemon

---

From: Yoav Nir <[email-masked]>
Date: Wed, 4 Mar 2015 00:06:01 +0200

> On Mar 3, 2015, at 11:56 PM, [email-masked] wrote:
> 
> 
> Hiya,
> 

I don’t think we should prefer things either way. There is a lot to say about the security of the web and the security of Internet email, but I don’t think any of the issues these protocols have is rooted in HTTP using two ports or SMTP using one.

With two ports, firewalls have an easier time either forcing or denying encryption (assuming that the applications have fall-back behavior), but firewalls have managed fine with SMTP for twenty years. I don’t think this is an issue either way. Of course, assigning one port instead of two saves on a scarce resource, but that is not a security consideration.

Yoav

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 3 Mar 2015 17:08:13 -0500

On Tue, Mar 3, 2015 at 5:06 PM, Yoav Nir <[email-masked]> wrote:

> I don’t think we should prefer things either way. There is a lot to say
> about the security of the web and the security of Internet email, but I
> don’t think any of the issues these protocols have is rooted in HTTP using
> two ports or SMTP using one.
>
> With two ports, firewalls have an easier time either forcing or denying
> encryption (assuming

Great point.

> that the applications have fall-back behavior), but firewalls have managed
> fine with SMTP for twenty years. I don’t think this is an issue either way.
> Of course, assigning one port instead of two saves on a scarce resource,
> but that is not a security consideration.
>
> Yoav
>
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

-- 

Thanks,
Kathleen

---

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Mar 2015 14:20:08 -0800

On 3 March 2015 at 14:06, Yoav Nir <[email-masked]> wrote:
> Of course, assigning one port instead of two saves on a scarce resource, but that is not a security consideration.

Of course, you can save the same number of ports and more of other
things by not having the non-secure option at all.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 3 Mar 2015 14:39:30 -0800

On Mar 3, 2015, at 1:56 PM, [email-masked] wrote:
> (one can muck up or do ok either way)

Quite true.

> and we also don't
> or two ports is generally "more secure".

Also quite true.

Thus, the document in question is quite wrong when it talks about "insecure ports". What the document author calls "insecure ports" are in fact ports that might have a STARTTLS-style upgrade on them. These are discussed in a few places in the document, all with pejorative language. Efforts to get this changed to reflect the lack of consensus got confusing text added.

> Of course, assigning one port instead of two saves on a scarce resource, but that is not a security consideration.

Ports are not a scarce resource, and the document does not argument that they are. That took *many* people to convince the author.

--Paul Hoffman

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Mar 2015 21:28:32 -0500

[email-masked] wrote:
    > A protocol that can run over TLS can be allocated two ports (like HTTP
    > with 80 and 443) or one port and use STARTTLS or similar.

    > Ted has a discuss [1] on a document about port number allocations and
    > asked if the security ADs cared. We think the answer is that we don't
    > (one can muck up or do ok either way) and we also don't think that the
    > security area actually has a consensus that one or two ports is

I think that it's mostly about how firewall administrators and middle-box
designers react.

I think that two ports encourage the firewall maker/administrator to consider
that they can (and should?) mess with the contents.

As for SMTP doing fine --- in many cases firewalls have terminated SMTP at
the firewall and then relayed things.  Probably the rise of spam has changed
the policy towards doing that over the decades, but I think it is instructive
to realize that whenever we have had different ports for encrypted and
non-encrypted, the non-encrypted port has had it's traffic, uhm, molested by
middle boxes.
(dictionary.com: molested: 1. to bother, interfere with, or annoy. 2.to make
indecent sexual advances to. 3. to assault sexually.  Yes, I think it's the right
term)

Speaking on this topic: had we a port-80 mechanism for HTTPS in 2.0, we would
then very very urgently need to write a BCP on captive portals, because once
the browser is sure that foo.com is secure, the captive portal will
definitely be seen as a MITM, and nothing will work.

If we anticipate that we'd like that option in the future, we need to only
slightly urgently write that BCP and find a way to force it out there (as in,
"ABC, XYZ Government and BIGCORP.com will not procure hotel rooms in hotels
that are not RFC-CAPTIVE-PORTAL compliant").  We already see this as an
impediment to DNSSEC deployment (because hijacking DNS is also done by
really stupid captive portals).

So: I am in favour of a single port for all new protocols.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Scott R. Corzine" <[email-masked]>
Date: Wed, 4 Mar 2015 02:25:59 -0500

> I think that it's mostly about how firewall administrators and middle-box

End users, client and server administrators can benefit from
encrypted-only ports when their policy is encryption only (more common
beyond SMTP). Their traffic will be encrypted or will fail, they won't
risk inadvertently falling back unnoticed to the cleartext connection
that is the default state. Configuration errors, incorrect
troubleshooting, bugs, and attackers all have potential to cause this.

Example: Using only 636/LDAPS in a Directory Services configuration
where we don't ever want non-encrypted traffic to be possible. Some
software can't fully protect connections to 389/LDAP that "require"
STARTTLS from clients with default configurations leaking
non-encrypted data.

Disabling 389 completely and only serving 636 at the server solves
this risk (at the cost of failing incorrect configurations). A client
only using 636 also has its traffic protected. It's much easier to
verify that 389 isn't listening than that it's always handling
STARTTLS correctly.

So there can be benefits to having two ports (or encrypted-only ports).

> non-encrypted, the non-encrypted port has had it's traffic, uhm, molested by

Looking at the list of two port protocols I'm pretty sure that this is
wrong (excluding devices affecting ALL non-encrypted traffic including
one port ones).

-Scott-

---

From: Joe Touch <[email-masked]>
Date: Wed, 04 Mar 2015 10:16:37 -0800

Hi, all,

It might be useful to also check RFC2595, Sec 7 on this point.

I.e., that establishes rough consensus on this point (as it is an RFC of
this area), and is PS.

It would be especially helpful if anyone could point to something PS or
higher that contradicts that analysis.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 04 Mar 2015 10:20:58 -0800

One point of clarification:

On 3/3/2015 2:39 PM, Paul Hoffman wrote:
> Ports are not a scarce resource, and the document does not argument
> that they are. That took *many* people to convince the author.

The current text, that incorporates LC comments, is here.

I.e., this statement is correct in the use of the term "scarce" was
changed to "limited" between versions -04 and -05. The basic statement
about their being limited and needing conservation remains.

Joe

---

6. Conservation

   Assigned port numbers are a limited resource that is globally shared
   by the entire Internet community. As of 2014, approximately 5850 TCP
   and 5570 UDP port numbers have been assigned out of a total range of
   49151. As a result of past conservation, current port use is small
   and the current rate of assignment avoids the need for transition to
   larger number spaces. This conservation also helps avoid the need
   for IANA to rely on port number reclamation, which is practically
   impossible even though procedurally permitted [RFC6335].

---

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 4 Mar 2015 10:34:52 -0800

> It might be useful to also check RFC2595, Sec 7 on this point.

Your reference to this document is disturbing for many reasons.

> I.e., that establishes rough consensus on this point (as it is an RFC of

Mainly that. RFC 2595 is about IMAP and POP (and the stillborn ACAP), not about any other protocols. It is also 15 years old and security operations have changed significantly since that time.

If SAAG folks think that a bullet-by-bullet discussion of that section is useful here on SAAG, I'm happy to engage.

--Paul Hoffman

---

From: Joe Touch <[email-masked]>
Date: Wed, 04 Mar 2015 10:43:36 -0800

On 3/4/2015 10:34 AM, Paul Hoffman wrote:
> Mainly that. RFC 2595 is about IMAP and POP (and the stillborn ACAP), not about any other protocols. 

The entire doc is about STARTTLS (the current PS protocol for using a
single port for both secure and insecure variants concurrently).

Sec 7 specifically addresses using STARTTLS for other protocols.

> It is also 15 years old and security operations have changed
> significantly since that time.

And it also has not been revised or updated.

If it's as inaccurate and outdated as you claim, it seems that this
group has some very immediate work to do.

Joe

---

From: Eliot Lear <[email-masked]>
Date: Wed, 04 Mar 2015 19:46:24 +0100

Stephen,

Yoav raises a good point, but I think the major piece of advice is this:
know what to expect before you connect: avoid downgrade attacks.

Eliot

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 4 Mar 2015 10:50:34 -0800

> group has some very immediate work to do.

If you're the only person who cares about this RFC, or even remembers that it exists, then "very immediate" seems a bit hyperbolic.

FWIW, I was one of the contributors to the RFC in question, so saying that it is mostly forgotten is not an insult to the work we did then.

--Paul Hoffman

---

From: Joe Touch <[email-masked]>
Date: Wed, 04 Mar 2015 10:56:41 -0800

On 3/4/2015 10:50 AM, Paul Hoffman wrote:
> If you're the only person who cares about this RFC, or even remembers
> that it exists, then "very immediate" seems a bit hyperbolic.

It's PS and it's a security area doc.

If it's not cared about or recalled, perhaps it might be useful for SAAG
to consider a Roadmap doc, as was done for TCP in transport.

I would hope that SAAG would focus "immediately" on widely deployed
security protocols that are inaccurate and outdated as a matter of course.

But that's just me. YMMV.

Joe

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Mar 2015 19:25:10 +0000

> higher that contradicts that analysis.

The main thing that resonates from Section 7 is the comment abourt
URI schemes.  

When each client knows whether TLS channel security is or is not
appopriate for a particular service, but some location service
needs to return a usable URI that works for multiple clients, things
work better when channel security is not explicitly part of the
URI.  Thus "imap://"  or "ldap://" is in some cases better than
"imaps://" or "ldaps://", because the client using the URI can then
apply appropriate policy.

For services with strict separation of TLS and non TLS by port and
URI scheme, the location service cannot return URIs that are channel
security neutral, and clients then have to request a security policy
specific version of the service location.

Of course sometimes the service dispensing the URI knows more about
which security policy is appropriate than its clients.  What we're
missing is URI schemes that mandate the use of TLS on "STARTTLS"
ports.  For example:

	ldaps://ldap.example.com:398/...

would not work because "ldaps" is LDAP inside SSL *without* STARTTLS.

On the other hand:

	ldap://ldap.example.com:389/

cannot express mandatory TLS, and leaves it up to the client
(sometimes that's the right thing to do).

If there were a URI scheme for required STARTTLS:
	
	ldaptls://ldap.example.com:389/

then the consolidated port would provide maximum flexibility:

	ldap://ldap.example.com:389/	(URI consumer decides)
	ldaptls://ldap.example.com:389/	(URI producer decides)

with split ports the decision is always at the URI producer.

For example, because HTTP/HTTPS have split ports, the proposed URI
DNS RRtype has messy security interactions with HTTP.  Unlike "A"
records, the URI payload carries security policy via the URI scheme.
(Redirection would still merit appropriate security considerations,
but the hypothetical picture is simpler).

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 4 Mar 2015 11:37:40 -0800

> The main thing that resonates from Section 7 is the comment abourt

Note that this not fully relevant to this thread, because most protocols that use ports don't have URI schemes. Your observations on the problems with foo: vs. foos: are good, but not as a reason for suggesting to application developers to not have a second port.

Also note that some applications that resolve pop: and imap: URI actually try to do STARTTLS regardless. This should be up to the application specifications and developers, not the port list maintainers.

--Paul Hoffman

---

From: Joe Touch <[email-masked]>
Date: Wed, 04 Mar 2015 15:55:57 -0800

On 3/3/2015 2:08 PM, Kathleen Moriarty wrote:
> 
> 
> On Tue, Mar 3, 2015 at 5:06 PM, Yoav Nir <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     With two ports, firewalls have an easier time either forcing or
>     denying encryption (assuming 
> 
> Great point.

How do you know what's on either port until you look with DPI?

Multiple ports used this way just propagates the myth that blocking a
port is a type of security.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 04 Mar 2015 15:59:44 -0800

> troubleshooting, bugs, and attackers all have potential to cause this.

Using a single port doesn't prohibit this requirement. A client that
doesn't want a downgrade attack simply doesn't accept that as a
response. A server that doesn't want to support "no encryption" doesn't
allow it.

Either way, it's all just configuration. Anything can be configured
incorrectly.

Joe

---

From: Joseph Salowey <[email-masked]>
Date: Wed, 4 Mar 2015 16:24:48 -0800

> Either way, it's all just configuration. Anything can be configured
[JAS] I've definitely seen many instances where the insecure port is left
open (and allowed through the firewall) because of bad configuration.
However, I see more implementation issues with changing the security
parameters on an existing connection. Configuration problems are easier to
correct than implementation problems.  This is somewhat orthogonal to the
one port/two port discussion since you can try to change security
parameters on an existing connection in either case.  The single port case
always has this possibility.  If you're careful then its often not
difficult to get right, but we are not always careful.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 5 Mar 2015 08:27:19 +0200

> On Mar 5, 2015, at 1:55 AM, Joe Touch <[email-masked]> wrote:
> 
> 
> 

You don’t. But it does block misconfigured endpoints from communicating in the way the firewall administrator doesn’t want. Malicious actors can try to tunnel their traffic over DNS queries or ICMP or TCP port 443.  Blocking a port is about enforcing correct configuration, not about preventing the communications altogether.

Yoav

---

From: Joe Touch <[email-masked]>
Date: Wed, 04 Mar 2015 23:19:17 -0800

On 3/4/2015 10:27 PM, Yoav Nir wrote:
> You don’t. But it does block misconfigured endpoints from
> communicating in the way the firewall administrator doesn’t want.

The only "way" port blocking blocks is the use of default ports. With
dynamic DNS and other endpoint coordination tools, that's not a
significant impediment to consenting endpoints that want to get around a
blocked port.

> Malicious actors can try to tunnel their traffic over DNS queries or
> ICMP or TCP port 443. 

Actors can - and do - do this already. They're not all malicious just
because they don't use ports in the default way. Registered ports are
only the default; ultimately, ports are meaningful only to the endpoints.

> Blocking a port is about enforcing correct
> configuration, not about preventing the communications altogether.

The only communication blocked by ports is that which makes the default
assumptions.

The real issue, AFAICT, is why an insecure port is even appropriate
anymore. Performance is a consideration, but consenting endpoints should
be able to figure that out via negotiation.

Joe

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Mar 2015 07:29:22 +0000

> be able to figure that out via negotiation.

Because the "secure" port is often unusable when the security
requirements are all or nothing, as we're well aware from the
opportunistic security discussions.

The only way to make the "secure" port be the only one, is to in
fact relax the definition of security to subsume a range of security
levels from (possibly cleartext) to fully authenticated and encrypted.

The cleartext outcome might be possible by skipping STARTTLS, or
by negotiating a NULL cipher.  Or might be prohibited but authenticaiton
would still be optional.

So for most applications the only way to have just one port is to
drink the opportunistic security cool-aid.  Only a small fraction
of applications which must be unconditionally fully protected for
all peers can be always "secure".

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 05 Mar 2015 12:14:43 -0500

> things by not having the non-secure option at all.

+1

I think someone on thie list wrote some RFC about pervasive monitoring and desiring crypto for all new protocols

This should be a legacy problem only.

Paul

---

From: Joe Touch <[email-masked]>
Date: Thu, 05 Mar 2015 09:38:58 -0800

> This should be a legacy problem only.

FWIW, there are three issues with legacy protocols:

1. a protocol that is currently unprotected and asks for a new protected
port
	there are no concerns here, AFAICT

2. a protocol that is currently protected and asks for a new unprotected
port
	there ought to be substantial concerns here,
	and AFAICT this ought to be strongly discouraged

3. a protocol that is currently protected one way, and asks for a new
protected port for a different method
	in general, ports should include enough support for
	version negotiation that this should not be needed

	however, if there's a substantive security concern, it
	also ought to be no issue (i.e., OK)

So I don't think there should be any legacy issues either.

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Mar 2015 15:30:37 +0000

Thanks folks, I think you've re-enforced my perception
that this is not something on which we have consensus.
It clearly is something where folks feel strongly, and
want to convince others, but that is not the same. If
someone wants to write a draft on the topic, then I'm
sure we can make space for discussion of that at a
future saag session (not Dallas, that's kinda full
already) and we could take it from there.

Ta,
S.

---

From: ianG <[email-masked]>
Date: Tue, 10 Mar 2015 20:04:50 +0000

> already) and we could take it from there.

Two ports correlates with lack of consensus.

Try mandating one port, and see if consensus follows ;)

iang