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

"t.petch" <> Thu, 11 November 2010 17:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE9D43A696B; Thu, 11 Nov 2010 09:43:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.429
X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MTr4DC1cXdgO; Thu, 11 Nov 2010 09:43:16 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C02173A69C2; Thu, 11 Nov 2010 09:43:15 -0800 (PST)
Received: from (HELO pc6) ([]) by with SMTP id ARF22125; Thu, 11 Nov 2010 17:43:29 +0000 (GMT)
Message-ID: <007d01cb81bf$548f3880$>
From: "t.petch" <>
To: Nicolas Williams <>, Marsh Ray <>
References: <><p06240843c8fd6c508084@[]><><><><><><><> <>
Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08)
Date: Thu, 11 Nov 2010 17:41:15 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4CDC2B26.0046, actions=tag
X-Junkmail-Status: score=10/50,
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4CDC2B4D.0028, ss=1, fgs=0, ip=, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine
X-Junkmail-IWF: false
Cc:,, Paul Hoffman <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Nov 2010 17:43:17 -0000

---- Original Message ----- 
From: "Nicolas Williams" <>
To: "Marsh Ray" <>
Cc: <>; "Paul Hoffman" <>; <>
Sent: Tuesday, November 09, 2010 7:11 PM
> 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
> > >>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