Re: [TLS] TLS Proxy Server Extension
Philip Gladstone <pgladstone@cisco.com> Wed, 03 August 2011 13:38 UTC
Return-Path: <pgladstone@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 139F721F8753 for <tls@ietfa.amsl.com>; Wed, 3 Aug 2011 06:38:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.923
X-Spam-Level:
X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6]
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 G7CxiJfCIrbU for <tls@ietfa.amsl.com>; Wed, 3 Aug 2011 06:38:03 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 735F621F8686 for <tls@ietf.org>; Wed, 3 Aug 2011 06:38:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=3917; q=dns/txt; s=iport; t=1312378695; x=1313588295; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=pVeS+BAKU3cVx9mRpW97Y5bmIpSLangJvH+/xl+Rvv0=; b=WnaQPzZIkgtPDuqE2F/q0SLw1+dalUDME+3geyEyEHd8PluybFrItN/P bGuSAIss2/mNY/4dTwzW5MkqRHxF+cla6QBRy6SjJvXRD1IsmjcdlKwyC 7yTR+VhnBzUemH71RbBBpx+BnpOY0f+PE+1H/VdvP086xWmUO5DCQ0IJP k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiAHABZOOU6rRDoG/2dsb2JhbAA5BgOER5QDjxZ3gUABAQEBAxIBEFUPAgsEFAkWCwICCQMCAQIBCTwTCAEBHqk1AY0rkT4CgyMZgXSBEASSe4UHi3k
X-IronPort-AV: E=Sophos;i="4.67,310,1309737600"; d="scan'208,217";a="9230097"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-5.cisco.com with ESMTP; 03 Aug 2011 13:38:15 +0000
Received: from [161.44.106.139] (dhcp-161-44-106-139.cisco.com [161.44.106.139]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p73DcE47004030 for <tls@ietf.org>; Wed, 3 Aug 2011 13:38:14 GMT
Message-ID: <4E394F44.9070909@cisco.com>
Date: Wed, 03 Aug 2011 09:38:12 -0400
From: Philip Gladstone <pgladstone@cisco.com>
Organization: Cisco Systems, Inc
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: tls@ietf.org
References: <1312373903.421.YahooMailClassic@web111718.mail.gq1.yahoo.com>
In-Reply-To: <1312373903.421.YahooMailClassic@web111718.mail.gq1.yahoo.com>
Content-Type: multipart/alternative; boundary="------------080606020405000109090303"
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, 03 Aug 2011 13:38:04 -0000
On 8/3/2011 8:18 AM, Ken Peirce wrote: > The TLS proxy exists today. It's two sessions in relay mode. The end user accepts the peer of the first session to be a trusted entity. If this trust is misplaced, that has nothing to do with the protocol. This is exactly true. The problem that we are trying to solve is to find out the actual identity of the server that the proxy has connected to. Further, we want the client to be able to validate the certificate of the server according to its own rules (which may include a different list of trusted root certificates). As people have pointed out, being able to understand the EV status of the remote server could be important. I think, based on the discussion, that there is a place for a new type of object in the TLS model -- the read-only proxy. This would require significant changes to the TLS protocol to support, and it might be significantly more difficult to implement than the current two TLS session approach. However, I suspect that until all proxies supported this new protocol, they would have to support the two TLS session model as well -- a viable strategy might be to try and negotiate the read-only proxy protocol and then fall back to the two TLS session model. Philip -- Philip Gladstone Phone: +1 978-ZEN-TOAD (+1 978 936 8623) Ham radio: N1DQ
- [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Yngve N. Pettersen
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Adam Langley
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Adam Langley
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Matt McCutchen
- [TLS] Certificate pins vs. MITM proxies Matt McCutchen
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension Matt McCutchen
- Re: [TLS] TLS Proxy Server Extension Matt McCutchen
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension Marsh Ray
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Marsh Ray
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension Marsh Ray
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Marsh Ray
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Marsh Ray
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Anders Rundgren
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Ken Peirce
- Re: [TLS] TLS Proxy Server Extension Peter Gutmann
- Re: [TLS] TLS Proxy Server Extension Matt McCutchen
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension Joshua Davies
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Ken Peirce
- Re: [TLS] TLS Proxy Server Extension Philip Gladstone
- Re: [TLS] TLS Proxy Server Extension Kemp, David P.
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Ralph Holz