Re: [TLS] TLS Proxy Server Extension

David McGrew <mcgrew@cisco.com> Wed, 27 July 2011 01:54 UTC

Return-Path: <mcgrew@cisco.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7C011E8093 for <tls@ietfa.amsl.com>; Tue, 26 Jul 2011 18:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiMFK1MzwpPC for <tls@ietfa.amsl.com>; Tue, 26 Jul 2011 18:54:13 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2F83111E8090 for <tls@ietf.org>; Tue, 26 Jul 2011 18:54:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=2432; q=dns/txt; s=iport; t=1311731653; x=1312941253; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=2YvS45ToNxpb9hMTD1/h9NC8upVF4t4hwUePhGBDcwc=; b=ZtO9DBSQ5GKOr3CN59CV6Az+JbmgM/cge8xjy6oZzAbRxl7u5K9C0q0X yqx6hHGpCnOSBi5qTjk29FcDqnpyzV8tuLxfHb4WFbivPbHDU/VtiSKcZ +SoDF3SPS89noCX00m/SC2iQ9ML4yLvfrpKlh3FZJVAVvLBFgpIV+TWP6 s=;
X-IronPort-AV: E=Sophos;i="4.67,272,1309737600"; d="scan'208";a="6745180"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 27 Jul 2011 01:54:13 +0000
Received: from dhcp-1783.meeting.ietf.org (bxb-vpn3-810.cisco.com [10.86.251.42]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6R1sCTK007396; Wed, 27 Jul 2011 01:54:12 GMT
Message-Id: <404C4877-EEAC-44F3-BFCD-401919B09A66@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: Yoav Nir <ynir@checkpoint.com>
In-Reply-To: <8FEC3C4B-32F9-46AF-A049-BE6FD3C2FE1A@checkpoint.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 26 Jul 2011 18:54:11 -0700
References: <E210EEE3-1855-4513-87E3-C315E611AB5E@cisco.com> <8FEC3C4B-32F9-46AF-A049-BE6FD3C2FE1A@checkpoint.com>
X-Mailer: Apple Mail (2.936)
Cc: Philip Gladstone <pgladstone@cisco.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS Proxy Server Extension
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2011 01:54:14 -0000

Hi Yoav,

thanks for the good suggestions.

David

On Jul 26, 2011, at 2: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
>>
>> http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-00
>
> 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
>