Re: [TLS] TLS Proxy Server Extension

David McGrew <mcgrew@cisco.com> Wed, 27 July 2011 02:04 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 004555E8012 for <tls@ietfa.amsl.com>; Tue, 26 Jul 2011 19:04:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Oc8Nkm6DkVnz for <tls@ietfa.amsl.com>; Tue, 26 Jul 2011 19:04:29 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C1E4F5E8018 for <tls@ietf.org>; Tue, 26 Jul 2011 19:04:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=1825; q=dns/txt; s=iport; t=1311732268; x=1312941868; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=r6FvzGKqQ0xhG9pzJozgKdXoTIutFyzmdgRgwDpJAgo=; b=UNJIoY7uZ443KDBmR7uzpgaxKozHciC+kJfZSjxNGEu/7K1rwPlEx8GS gEOXnWhTsRluqp8bmhZNuFYls3EBvHWAVQ/zL1c/btIRqnTpj9oVtFe+i O9OGugzrZlo1m4NWHpSUmRpWf6PJaN0+9fL1xKJwzCWfS72STzgaWnMQ+ A=;
X-IronPort-AV: E=Sophos;i="4.67,272,1309737600"; d="scan'208";a="104522010"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 27 Jul 2011 02:04:26 +0000
Received: from dhcp-1783.meeting.ietf.org (bxb-vpn3-810.cisco.com [10.86.251.42]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6R24Pxq009125; Wed, 27 Jul 2011 02:04:25 GMT
Message-Id: <8D96B7EB-4A2E-4EC8-8BF4-FF272C50C838@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: Adam Langley <agl@google.com>
In-Reply-To: <CAL9PXLyDdeA4FcWGZF3fUxPoJY=1q1QMvJ=y7Q_Oc8Txj4ofvg@mail.gmail.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 19:04:24 -0700
References: <E210EEE3-1855-4513-87E3-C315E611AB5E@cisco.com> <8FEC3C4B-32F9-46AF-A049-BE6FD3C2FE1A@checkpoint.com> <CAL9PXLwXqssrwDM4HytB_eNBT-LFK5fRAOVQ-ehd1XwhH6-8Ag@mail.gmail.com> <FCA03B83-11E6-4AA6-9ACD-42CDAD14FC46@checkpoint.com> <CAL9PXLyDdeA4FcWGZF3fUxPoJY=1q1QMvJ=y7Q_Oc8Txj4ofvg@mail.gmail.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 02:04:30 -0000

Hi Adam and Yoav,

On Jul 26, 2011, at 2:51 PM, Adam Langley wrote:

> On Tue, Jul 26, 2011 at 5:41 PM, Yoav Nir <ynir@checkpoint.com> wrote:
>> Really?  I thought Chrome used the operating system TA store. How  
>> can it tell the difference between a trust anchor that was  
>> installed by Microsoft and one that was installed by the user?
>
> Not in any very clean way I'm afraid:
>
> http://src.chromium.org/viewvc/chrome/trunk/src/net/base/x509_certificate_known_roots_win.h?revision=80765&view=markup
>
>> But I know that the EV indication goes away behind a proxy, and  
>> there's no way to make your CA certificate "EV" to the browser.  
>> Dave's proposal allows the green label to come back.
>

I like the succinct way that you put it.

> I've poked BlueCoat at least about this problem in the past and they
> didn't appear to be too exercised by it. It's really the MITM folks
> who need to figure out if this address their needs or not. I simply
> don't know the requirements in this space well enough to know if the
> draft meets them. From my point of view, we keep MITM in the back of
> our minds but otherwise mostly ignore them except to ban certain
> troublesome vendors from time to time.
>

I believe that the approach in the draft meets the broad requirements  
of many MITM devices and services: it doesn't require much new session  
state, or new policy that would need to be coordinated or managed, and  
there is not too much additional computation.  That plus it adds back  
security, which is important in general and is especially important  
for proxy devices that are providing security services.   But I can't  
claim to have broad knowledge of all such devices, so it will be  
useful to hear from others in this space.

David

>
> Cheers
>
> AGL