Re: [TLS] TLS Proxy Server Extension

Yoav Nir <> Tue, 26 July 2011 21:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8BD2F21F888A for <>; Tue, 26 Jul 2011 14:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.492
X-Spam-Status: No, score=-10.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W19-4pOyGTGa for <>; Tue, 26 Jul 2011 14:20:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 06DF721F856B for <>; Tue, 26 Jul 2011 14:20:46 -0700 (PDT)
X-CheckPoint: {4E2F3D42-9-1B221DC2-FFFF}
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id p6QLKgsR001319; Wed, 27 Jul 2011 00:20:42 +0300
Received: from ([]) by ([]) with mapi; Wed, 27 Jul 2011 00:20:42 +0300
From: Yoav Nir <>
To: David McGrew <>
Date: Wed, 27 Jul 2011 00:20:40 +0300
Thread-Topic: [TLS] TLS Proxy Server Extension
Thread-Index: AcxL2d92M4NsQp0EQQmaKlhg2ovHuw==
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail-2-548075153"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Cc: Philip Gladstone <>, " List" <>
Subject: Re: [TLS] TLS Proxy Server Extension
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Jul 2011 21:20:48 -0000

Also, I'd lose section 3.2.  It doesn't add much :-)

On Jul 26, 2011, at 5:17 PM, Yoav Nir wrote:

> On Jul 26, 2011, at 11:01 AM, David McGrew wrote:
>> Hi,
>> I would like to request feedback on a new draft that Philip Gladstone  
>> and I put together, which aims to solve some of the security problems  
>> that happen when there is a (HTTP) proxy present and TLS is in use.    
>> The approach is to require the proxy to provide the client with  
>> additional information that the client can use to make a well-informed  
>> decision about the security of the session.  This draft was put  
>> together too late to request a slot at the WG meeting this week, but  
>> if you have thoughts on either the goals or the mechanism, we can  
>> discuss either in person or on the list.
>> David
> Hi Dave.
> I like this draft. TLS proxies are becoming a fact of life. They still have significant drawbacks in that the "fake" certificates that they generate are not identical to the original certificates. For example, the fake certificates cannot be EV certificates, and therefore the users lose the "green-bar" indication.
> I don't know if you're following the LockFoo discussion on WebSec, but all of those locks would cause a hard-fail for clients connecting to sites that have specified them. As security people we might think "good!", but that would actually be a bar to implementations of LockFoo more than it would be a bar to deployment of TLS proxies. Giving the client access to the original certificates would allow the browser to overcome this limitation.
> A similar argument also applies to DANE. If the DNS entry identifies the key, the certificate or the CA, then the "fake" certificate would cause an error. Access to the original certificate chain allows the client to eliminate the error message, although I am not sure how the browser UI would indicate an EV certificate proxied through a non-EV proxy.
> I am wondering why you would need the ConnectionSecurityParameters structure. Wouldn't the 2-byte ciphersuite be a more compact way to represent this information?
> Also I would add text about EV certificates (and maybe also the LockFoo cases of DANE and WebSec) to the motivation section.
> Yoav
> Scanned by Check Point Total Security Gateway.
> <smime.p7s><ATT00001..txt>