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 Tue, Nov 09, 2010 at 12:19:25AM +0100, Richard Hartmann wrote:
> On Mon, Nov 8, 2010 at 23:22, Nicolas Williams
> <[e-mail]> wrote:
> > If the firewall is not close to the client then the client can still
> > fallback on no TLS.
> 
> True. I understood your example as "if you only allow TLS, an
> overloaded port makes things easier for the firewall admin" which I
> did not agree with.

Provided that all servers and clients of interest implement the the app
protocol on the raw TLS ports, then yes, it's easier for the firewall
admin to only open the raw TLS ports.

> > There's trade-offs all over.  I'm not sure that this one is worth all
> > that much either way.  I prefer StartTLS over having two ports for
> > everything.
> 
> I doubt that everyone will rush to register new ports.

But ports are a limited commodity.

> >  I might also be happy with forcing TLS on always for new
> > ports,
> 
> IMO, this is not realistic.
> 
> > but I do worry about training users to click through the
> > "is this the right server" dialog ("leap-of-faith").
> 
> Agreed.

So what you propose is... what exactly?  That every application protocol
have raw TLS and non-TLS (but with StartTLS?) ports?  Or that every
application be based on HTTP(S)?

I'm proposing this: stop the FUD regarding StartTLS, bake it into all
new app protocols where TLS is appropriate.  In existing apps that have
both raw TLS and non-TLS ports, leave well enough alone.

Nico
--