Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08)

From: Chris Newman <[email-masked]>
Date: Wed, 09 Feb 2011 18:12:18 -0800

I know I'm very late on this topic, but my position differs from others so 
I'll comment.

I can not deny that separate-port for SSL is simpler to implement on the 
server side (having done both). Since the odds of security bugs increases 
with the amount of code, I must conclude that separate-port SSL is more 
secure for _implementers_ and _implementations_ for that reason alone.

However, I believe STARTTLS is more secure for _operators_ and 
_administrators_. The separate port model creates an illusion that there is 
a "secure" and "insecure" variant of the protocol and that a single 
firewall setting magically makes the application secure. In general, this 
is not true. Most servers have several security settings and the default 
settings have to compromise between common practice, secure-by-default 
practice, deployability, management complexity and usability. There is, in 
general, no way to make a server installation secure for a given site other 
than to understand the security settings that server provides and set them 
properly.

A protocol that uses STARTTLS thus has the advantage of forcing the 
administrator/operator to look at the server's security settings to make 
the installation secure, thus increasing the odds of success relative to 
the separate-port model where an administrator might falsely assume they're 
done after blocking the non-SSL port.

While I think the judgment call is close for separate-port-SSL-vs-STARTTLS, 
I prefer STARTTLS weighing all the factors.

And for the record I'm responsible for TLS integration into a server 
product and maintain all the relevant code and find STARTTLS maintenance 
annoying. I'm also author of RFC 2595, so perhaps that balances out my bias 
as an implementer. ;-)

It's also my opinion that a high quality client should use a "latched" 
model by default. If the client ever sees "STARTTLS" advertised and 
negotiates it successfully, the client records the fact in a local 
operations file that it used STARTTLS with server X. Subsequent to that it 
will require STARTTLS with server X and not back off. I will note that 
implementation strategy is simpler with the STARTTLS model than with the 
separate port model.

As an aside, there is no interoperable specification for use of TLS client 
certificate authentication with the "pops" protocol (does it start in 
not-authenticated state and require an AUTH EXTERNAL, or does it start in 
authenticated state -- no way to distinguish the two cases). However, use 
of TLS client certificate authentication with POP+STLS according to written 
rules in RFC 2595 does interoperate.

		- Chris

--On November 8, 2010 11:14:35 +0800 Magnus Westerlund 
<[email-masked]> wrote:

> TLS experts,
>
> There currently a WG last call ongoing in on the IANA Procedures for the
> Management of the Service Name and Transport Protocol Port Number
> Registry update document.
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/
>
> A WG last call comment on this document was raised by Paul Hoffman:
> http://www.ietf.org/mail-archive/web/tsvwg/current/msg10305.html
>
> My summary of that comment is that STARTTLS for SMTP (RFC 3207) has
> shown to have some security issues, be complexer to implement than using
> two ports and thus less popular. Thus the registration rules should be
> less restrictive in assigning an additional port for TLS version of
> services/applications/protocols.
>
> The downside of less restrictive port allocation rules is that the port
> space will be consumed at a higher rate. Thus there is need to determine
> what is the most suitable trade-off here.
>
> Clearly if the security issues are serious when one multiplex TLS and
> non-secured version of the protocol on the same port we must allow such
> port allocations. However if the issues are minor and the primarily
> issue is implementation complexity then saving the limited port space is
> probably more important.
>
> Your input into these questions would be very appreciated.
>
> Thanks
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: [email-masked]
> ----------------------------------------------------------------------
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Nico Williams <[email-masked]>
Date: Wed, 9 Feb 2011 20:25:41 -0600

> I know I'm very late on this topic, but my position differs from others so

+1

But I'll also add that it's not necessarily harder for implementers to
manage StartTLS with isolation.  I realize that implementers have
screwed this up in the past, but there is hope that we can learn, and
even develop institutional memory -- if not we have other problems.

Nico
--

---

From: Matt DeMoss <[email-masked]>
Date: Wed, 9 Feb 2011 22:35:59 -0500

> secure for _implementers_ and _implementations_ for that reason alone.
 [...]

> authenticated state -- no way to distinguish the two cases). However, use of
> TLS client certificate authentication with POP+STLS according to written
I think the argument for protecting complex code paths from exposure is much
stronger in the case of required client certificate authentication where
unauthorized users may be able to exercise fewer paths.

There are also some cases where it seems like you get client-cert-auth 'for
free' as a side effect of sitting on top of a TLS implementation that
supports client auth. MS Outlook seems to like this with LDAPS: I doubt it
was a conscious choice on their part to include that mode of authentication.

The separate port model also makes it easier to terminate the TLS tunnel at
a simple load balancing or TLS accelerating device that knows nothing of the
underlying protocol.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 10 Feb 2011 09:19:15 +0200

I have to disagree with this.

> done after blocking the non-SSL port.

I think this is a recipe for failure. What you're saying here, is that by using separate ports, you cannot use the firewall to prevent non-secure connections and this forces the administrator to configure the server properly.

There are several things wrong with this:
1. It does not force the administrator to configure the server properly. At best, it forces them to find the "force SSL" checkbox and check it. That has pretty much the same effect as forcing this on the firewall. Some administrators will use any opportunity to configure the server wrong.
2. You underestimate firewalls. Modern firewalls can examine connections and cut them off if STARTTLS is not initiated in time. So the administrator still has the option of "fixing it in the firewall".

In short, you can't force administrators to do the right thing. Ever.

---

From: Joe Touch <[email-masked]>
Date: Fri, 11 Feb 2011 15:48:27 -0800

FWIW, we have removed the text on this recommendation from this draft (a 
version will appear later today).

However, I'd still appreciate resolving this issue, or at least 
clarifying the two different positions in detail, as part of a different 
draft that focuses on advise to how ports are used:

http://tools.ietf.org/html/draft-touch-tsvwg-port-use-00

That doc will be updated in the next few days with more than just 
placeholders, and I'll include space for this debate there as well.

FYI.

Joe

On 2/9/2011 6:12 PM, Chris Newman wrote:
> I know I'm very late on this topic, but my position differs from others
> so I'll comment.
>
> server side (having done both). Since the odds of security bugs
> increases with the amount of code, I must conclude that separate-port
> SSL is more secure for _implementers_ and _implementations_ for that
> reason alone.
>
> _administrators_. The separate port model creates an illusion that there
> is a "secure" and "insecure" variant of the protocol and that a single
> firewall setting magically makes the application secure. In general,
> this is not true. Most servers have several security settings and the
> default settings have to compromise between common practice,
> secure-by-default practice, deployability, management complexity and
> usability. There is, in general, no way to make a server installation
> secure for a given site other than to understand the security settings
> that server provides and set them properly.
>
> the separate-port model where an administrator might falsely assume
> they're done after blocking the non-SSL port.
>
> While I think the judgment call is close for
> separate-port-SSL-vs-STARTTLS, I prefer STARTTLS weighing all the factors.
>
> annoying. I'm also author of RFC 2595, so perhaps that balances out my
> bias as an implementer. ;-)
>
> operations file that it used STARTTLS with server X. Subsequent to that
> it will require STARTTLS with server X and not back off. I will note
> that implementation strategy is simpler with the STARTTLS model than
> with the separate port model.
>
> As an aside, there is no interoperable specification for use of TLS
> client certificate authentication with the "pops" protocol (does it
> start in not-authenticated state and require an AUTH EXTERNAL, or does
> it start in authenticated state -- no way to distinguish the two cases).
> However, use of TLS client certificate authentication with POP+STLS
> according to written rules in RFC 2595 does interoperate.
>
> - Chris
>