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

[Chris Newman <[e-mail]>]

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 
<[e-mail]> 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  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>