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:22:41AM -0700, Steingruebl, Andy wrote:
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
> > Nicolas Williams
> > 
> > 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.
> 
> Maybe I missed it but from a performance standpoint how do you solve
> the fast restart problem with StartTLS bootstrapping instead of
> implicit-TLS with a dedicated port?  Seems like for anything that is
> user-interactive (HTTP, etc) rather than async (SMTP) that the
> performance differences will be extreme. Yes?

First, I'm not proposing that we all start using StartTLS in HTTP.
HTTPS is here to stay.  IIRC the OP was talking about StartTLS in SMTP.

Second, I don't think "the performance differences will be extreme".
StartTLS implies one more round-trip.  That sucks, but for apps that
tend to maintain long-lived connections it's a wash.  For HTTP it's not
a wash, I agree.

> I think the downgrade attacks can both be solved with the
> oft-discussed generic "Strict Transport Security" work going on in
> multiple forums, and isn't dependent on which TLS bootstrap mode we
> choose, implicit, or StartTLS variety.

The downgrade problems are only solved by the client/user knowing that
fallback on not using TLS is not in their interest.  Note that forcing
TLS on all the time isn't a solution either unless at least servers are
authenticated by TLS all the time too (i.e., fallback on ADH is not good
either).  I think I've just agreed with what you wrote.

Nico
--