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

Marsh Ray <> Thu, 11 November 2010 18:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF7823A6892; Thu, 11 Nov 2010 10:16:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.382
X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, J_CHICKENPOX_15=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JH706+ZB4v70; Thu, 11 Nov 2010 10:16:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 233123A67B2; Thu, 11 Nov 2010 10:16:55 -0800 (PST)
Received: from ([]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1PGbi9-000Dks-7s; Thu, 11 Nov 2010 18:17:25 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id CC5026019; Thu, 11 Nov 2010 18:17:22 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX1/EomebJKl2/2eFiyre6nbtKqe29f246V0=
Message-ID: <>
Date: Thu, 11 Nov 2010 12:17:22 -0600
From: Marsh Ray <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101027 Thunderbird/3.0.10
MIME-Version: 1.0
To: "t.petch" <>
Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08)
References: <><p06240843c8fd6c508084@[]><><><><><><><> <> <007d01cb81bf$548f3880$>
In-Reply-To: <007d01cb81bf$548f3880$>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 12 Nov 2010 08:06:55 -0800
Cc: Paul Hoffman <>,,, Nicolas Williams <>
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 18:16:56 -0000

On 11/11/2010 10:41 AM, t.petch wrote:
> 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).

Well, that's the thing. In theory there is no difference, in practice 

Look at HTTP/HTTPS as an example. It doesn't use STARTTLS to negotiate 
an optional security upgrade. Well there is an RFC for it but I've never 
heard of anyone using it, if that functionality is latent, no one is 
depending on it.

The first thing users learn about web security is to put the 's' on the 
end of HTTPS.

The first thing web developers/admins do when setting up a secure site 
is to bind it to port 443. They can set port 80 to redirect port 443. 
The web developer can easily test that this is working in his web 
browser. The web site publishes 'https:' links and the user bookmarks 
them. If the TLS isn't working, no data is transferred. The TLS isn't 
optional. (You might raise the point that most users don't know the 
difference, but consider all the programmatic SOAP/web service clients 
which do.)

On the other hand, my email program gives me an option to use 
"STARTTLS". Even after I took packet captures of the connection process 
and observed it correctly negotiating the use of encryption, I still 
cannot tell if my email is vulnerable to a downgrade attack. The only 
way to find out is by performing exhaustive testing with an attack tool, 
or by direct inspection of the source code!

There are certainly a lot of things we could say about HTTPS security, 
but I believe that in this case has something valuable which 
STARTTLS-based protocols typically do not.

- Marsh