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 11:51:18AM -0600, Marsh Ray wrote:
> On 11/08/2010 09:50 PM, Nicolas Williams wrote:
> However, doesn't there need to be
> 
> >SSH has been so successful in large part because leap-of-faith works
> >rather well -- it has a very small window of vulnerability, a very big
> >vulnerability, yes, and requiring persistent storage, true, but
> >difficult to exploit without users eventually noticing.
> 
> I know I read a study somewhere of what users (a university setting
> I think) typically did when presented with the "WARNING: REMOTE HOST
> IDENTIFICATION HAS CHANGED!...Are you sure you want to continue
> connecting (yes/no)?" question. I think the results were pretty
> dismal.

For small deployments (say, home networks) the user can know that the
keys shouldn't have changed.  For larger-but-still-smallish deployments
this is a problem, and for sufficiently large deployments it's not a
problem at all because large organizations should be using GSS/Kerberos,
PKI, or else should be distributing known_hosts files, preferably via
DNSSEC.

> >>In that sense, egress rules on client-based firewalls could be as
> >>important as the inbound connections on the server side.
> >
> >So what you're proposing is that we require TLS on all the time, via raw
> >TLS ports?
> 
> Not really, although it wouldn't be a bad idea to migrate in that
> direction. I'm more trying to ask a philosophical question.

Philosophy is fine, but the original poster proposed something concrete
(that we drop StartTLS and just always use raw TLS); we should have an
answer to that.  Mine is that the arguments against StartTLS are weak,
and the arguments for always using raw TLS are also weak.  I'm
unconvinced by the OP's and others' arguments against StartTLS.

> We know that the properties we expect of the "secure communications"
> we discuss in in this WG depend on authentication or authenticated
> encryption. Authentication is thus something of a prerequisite for
> the security, unless we have justification to rule out the
> possibility of an active attacker. Although there are many scenarios
> in practice where active attacks are more difficult, any
> general-purpose protocol will have to resist them effectively.

Yes.  But don't go to extremes, don't rule out leap-of-faith.  I'd be
very cross if I had to deploy a PKI in my house :)

> So, except in cases where explictly unauthenticated endpoints are
> involved, isn't it reasonable that for WG discussions to presume
> that a security protocol will be building upon some form of trust
> framework?

Yes, but what does that have to do with the OP's post?

> Or is there a new world happening where we're retreating from that
> principle and we now expect systems to somehow bootstrap their own
> security out-of-the-box or not get used at all?

Bootstrapping security is a good thing.  Ideally we'd all have
smartcards and we could use those to bootstrap joining systems to a PKI,
Kerberos realm, etcetera, but often all we have is passwords, and
sometimes not even that.  For small scale deployments leap-of-faith
works wonders.  For larger scale deployments you can rely on capable IT
departments to pre-load trust anchors, etcetera.

Nico
--