Re: [TLS] TLS Proxy Server Extension

David McGrew <mcgrew@cisco.com> Mon, 01 August 2011 12:32 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 13CCB11E8251 for <tls@ietfa.amsl.com>; Mon, 1 Aug 2011 05:32:12 -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 aanKqPPsg7II for <tls@ietfa.amsl.com>; Mon, 1 Aug 2011 05:32:11 -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 36A5411E822F for <tls@ietf.org>; Mon, 1 Aug 2011 05:32:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=2285; q=dns/txt; s=iport; t=1312201937; x=1313411537; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=7hpsVk/Xcs88Sw97gJBeW/sH2gZcozWX0bo1jLO/f2Y=; b=VIi8rmP3fWbxmOgFBjCI5gY8BJ7fLV1weP7159h9RnD92WO709Hnrqy0 XqeKD1NU85n7KoEywRNFlyWaSrhfPrV0yYtdmGzF5AO6yHZxDfbl/XCQg O0DjZTo91sD+WqERd9NWP4hmvh+074hQT2BByODz/FQ8gjnGhLIfpob3D 8=;
X-IronPort-AV: E=Sophos;i="4.67,300,1309737600"; d="scan'208";a="105992204"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 01 Aug 2011 12:32:14 +0000
Received: from stealth-10-32-254-211.cisco.com (stealth-10-32-254-211.cisco.com [10.32.254.211]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p71CWBFF028329; Mon, 1 Aug 2011 12:32:12 GMT
Message-Id: <D70730D9-C704-464A-A344-A629D47F9082@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: Yoav Nir <ynir@checkpoint.com>
In-Reply-To: <CA5C2B11.4911%ynir@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: Mon, 1 Aug 2011 05:32:11 -0700
References: <CA5C2B11.4911%ynir@checkpoint.com>
X-Mailer: Apple Mail (2.936)
Cc: "pgladstone@cisco.com" <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: Mon, 01 Aug 2011 12:32:12 -0000

On Aug 1, 2011, at 12:15 AM, Yoav Nir wrote:

>
>
> On 8/1/11 9:28 AM, "Marsh Ray" <marsh@extendedsubset.com>; wrote:
>
>>
>>> The intent of the authors is to enable TLS to be
>>> used when an proxy is present,
>>
>> But the intent of TLS is to prevent man-in-the-middle attacks,  
>> i.e., to
>> prevent you from proxying it.
>>
>> Just because you can exploit it almost reliably with a custom root  
>> CA on
>> today's clients doesn't mean that it's not deeply contrary to the
>> security architecture of TLS.
>>
>> Design a secure way for the legitimate endpoints to agree to share  
>> some
>> session key material with you in a way that doesn't impersonate  
>> anyone.
>> I might even support such an extension (but good luck convincing the
>> servers of the world).
>
> Actually, with this extension, the proxy does not need to generate a  
> "fake
> certificate". It's fine for the proxy to present a certificate for
> "CN=tlsproxy.example.com" and convey the real certificate in the
> extension. Of course, clients would have to explicitly trust the  
> proxy,
> but that can be added as part of adding support for the extension.

Agreed.  It may also be desirable to add an authorization attribute to  
the certificate to explicitly label it as a proxy certificate.

>
> As for servers, it's possible to change the tls-proxy format in
> ClientHello to have a "role" field that could be either "client" or
> "proxy". Then the servers would be able to reject connections from
> proxies. Would that make it more acceptable?

This is a good idea.  It does not provide strong authentication of who  
the proxy is, but it does inform about its presence.

David

>
>>
>>> and to make clients informed about both
>>> the proxy and the server, and to provide cryptographically strong
>>> authentication of both.
>>
>> This concept of polyamorous TLS is more radical than its proponents  
>> want
>> to accept.
>
> Practically, I don't see this happening. The IETF generally does not
> radically alter protocols to fit the needs of middleboxes, it's the
> middleboxes that have to adapt at least at first. Later we do see  
> how the
> active mode of FTP replaces the passive mode because it fits NAT  
> better.
>
>