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

[Joe Touch <[e-mail]>]

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.
>
> 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
>>
>
>
>
>