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