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

[Nicolas Williams <[e-mail]>]

On Mon, Nov 08, 2010 at 11:27:46AM -0600, Marsh Ray wrote:
> On 11/08/2010 03:07 AM, Paul Hoffman wrote:
> >
> >"some security issues": See the long Security Considerations section
> >on RFC 3207.
> 
> Hmmm, yes, the little matter of the downgrade attack.

You have that with the out-of-band negotiation case too though.

1. Try the TLS port.

   Fail.

2. ???

   If you connect to the non-TLS port you've just been downgraded,
   possibly not on purpose.  Or maybe the client will then try StartTLS
   and give up if the server won't.

   If the client falls back on not using TLS at all then you have a
   problem.

Every IM and e-mail client I've used has the option to not require TLS.
That means they can be configured to fall back on not using TLS at all.
Worse, there's usually a checkbox for using TLS as opposed to a checkbox
for being insecure -- as a result, regardless of what the default is for
that checkbox the user is likely to check it off if they run into any
trouble.

> It's a decision that ends up in the hands of the admin anyway.
> Admins are already maintaining the ACLs on their firewall.

Yes.

> What are the advantages of running different versions of a protocol
> (having radically different security properties) on the same vs.
> different TCP ports?
> 
> As I see it, running on different ports has some advantages:
> 
> * Developers don't have to implement and test protocol support for
> some negotiation scheme.
> 
> * Developers don't have to code support for configuration

When was the last time you saw a major IM or e-mail client that didn't
let you toggle TLS?  I can't remember when I last saw such a thing.

If such an app gives you that toggle it's because the developers were
willing to deal with the complexity of negotiation (whether starttls or
not) and configuration (that toggle is it).

> * Admins don't have to learn more configuration, site security
> doesn't depend as much on the perfection of sendmail.cf.

If you're going to use TLS chances are you'll be depending at least on
server certs, and at least a small PKI or pre-shared self-signed certs
or client-side SSH-style leap-of-faith.  The PKI approach -> lots of
admin (TA deployment, CA cert signing procedures, ...).  Making sure
that servers require TLS, whether StartTLS or otherwise, is not much
harder.

> I think a secure-only port number is the superior solution for many
> reasons. The ability to reliably block insecure connections based on
> looking only at the TCP/IP header is a powerful thing.

You still have to be sure that the client and server will actually, you
know, run TLS.

The only benefit of a "secure-only port number" is that you don't have
to make sure that the server requires TLS -- chances are near 100% it
just won't work if it doesn't, in which case the problem is self-
correcting (user files ticket, admins fix the problem).

Nico
--