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

---- Original Message ----- 
From: "Nicolas Williams" <Nicolas.Williams@oracle.com>
To: "Marsh Ray" <marsh@extendedsubset.com>
Cc: <tls@ietf.org>; "Paul Hoffman" <paul.hoffman@vpnc.org>; <tsvwg@ietf.org>
Sent: Tuesday, November 09, 2010 7:11 PM
<snip>
> 
> 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.

To return to (what I see as) the main purpose of the thread, I too
think that StartTLS is a good, if not an excellent idea; I see no 
difference in the vulnerabilities (although my cryptanalysis is weak).

Sadly, whenever I have been involved in a WG developing App-X 
over TLS, my record of convincing the rest of the WG is 100% failure.

Also, this decision, StartTLS or separate ports, tends to be taken 
early in the development cycle, while the request to IANA will only materialise
five years or so later, so back pressure from IANA or the IESG will then meet
an immovable mountain.  Really, any advice to a WG needs to put in front
of them about the time the BOF is approved, which I don't see this I-D 
having any material impact on!

Tom Petch

> 
> > 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
> -- 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls