Re: [TLS] TLS Proxy Server Extension

David McGrew <mcgrew@cisco.com> Mon, 01 August 2011 12:25 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 C8C0711E814A for <tls@ietfa.amsl.com>; Mon, 1 Aug 2011 05:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.467
X-Spam-Level:
X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=-0.468, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, 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 shY+aUo7VaDN for <tls@ietfa.amsl.com>; Mon, 1 Aug 2011 05:25:49 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 01DCB11E816C for <tls@ietf.org>; Mon, 1 Aug 2011 05:25:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=5486; q=dns/txt; s=iport; t=1312201555; x=1313411155; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=FGkMZ+otAwX4uXcPL4yw4jZXiq2J86L7TKXSMfP5yFM=; b=dch0GAnL13SRm6h1/ME/ppp15WSxOiZhchqKeCKd6ShkSR9XOBH2QprP eEz4a+oIVHW267g09tqbdSGFOCVmSqdlqccq4y05xIqPbuHjYiugL+MHs FH+l6X2ZoSae1anyFoQakRUex9WOu3IoO8G6COMFsyp8/15nm8uF2EMy/ 4=;
X-IronPort-AV: E=Sophos;i="4.67,300,1309737600"; d="scan'208";a="8410362"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-8.cisco.com with ESMTP; 01 Aug 2011 12:25:55 +0000
Received: from stealth-10-32-254-211.cisco.com (stealth-10-32-254-211.cisco.com [10.32.254.211]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p71CPrDd026305; Mon, 1 Aug 2011 12:25:53 GMT
Message-Id: <7064FD6B-D0E4-44A5-B794-FA31F5A2CCC2@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: Marsh Ray <marsh@extendedsubset.com>
In-Reply-To: <4E364790.3000305@extendedsubset.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:25:52 -0700
References: <201107292044.p6TKinFB022634@fs4113.wdf.sap.corp> <D142B8F0-3F3C-4D69-918E-C15F42E84CBF@cisco.com> <4E337BF4.8030307@extendedsubset.com> <145F5A54-7702-4C82-BB39-C630E02E1A99@cisco.com> <4E364790.3000305@extendedsubset.com>
X-Mailer: Apple Mail (2.936)
Cc: pgladstone@cisco.com, 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:25:49 -0000

Again, it seems that you do not quite understand what we are trying to  
achieve.   There is current practice that uses proxies in a way that  
is bad for clients (and you outline many of the reasons below).  We  
aim to improve the situation for clients and the security of the  
overall solution.  One important point: it is possible to design a  
solution in which the proxy does not contain a CA.

Propagating TLS session key material is a worse idea for a lot of  
reasons.  It would be a fragile solution in which easy-to-make  
implementation mistakes could undermine security.  It would require  
considerable new implementation work.  It would make crypto validation  
considerably harder if not impossible.   If it aimed to preserve end- 
to-end authentication, it would be fundamentally incompatible with  
Authenticated Encryption in general and the AEAD facility in TSL 1.2  
in particular, and it would probably end up getting misused and abused  
in practice.  If it did not aim to preserve end-to-end authentication,  
then it would require considerable changes to the TLS protocol, to  
prevent keystream insertion attacks and keystream re-use.  Perhaps  
worst of all, it would create a mechanism that could more easily be  
abused; a server could (mis)use it and give away session keys without  
the knowledge or consent of the client.

I will work to make the next version of the draft more clear and more  
complete.

David

On Jul 31, 2011, at 11:28 PM, Marsh Ray wrote:

> On 07/30/2011 08:20 AM, David McGrew wrote:
>> It seems that you do not understand the intent of the draft or the  
>> authors.
>
> The intent is nearly irrelevent. The text of the spec and the bits  
> on the wire are what matters.
>
>> The use case here is web filtering as it is used by organizations and
>> consumers, in which a consumer or an organization chooses to use a
>> service or a product that acts as an HTTP proxy, and configures their
>> clients to do so. It is desirable in such cases to use TLS whenever
>> possible, and it is certainly desirable that the client be able to
>> authenticate the proxy.
>
> HTTP has explicit support for proxies and you can connect to them  
> securely via TLS already. Wouldn't this all be done more  
> appropriately at the HTTP layer?
>
>> 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).
>
>> 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.
>
> Current TLS:
> Client strongly authenticates server via trusted CA
> Server may authenticate client, but usually server relies on client  
> to stop S-C MitM
> Any proxy can only slow or drop connections
>
> "TLS proxy" via root cert on client:
> Client can't authenticate server any stronger than weakest proxy  
> allows
> Client may not even be aware of proxies
> Any proxy may degrade security of connections arbitrarily
> Any proxy may get pwned and expose its root CA private key
> Any proxy may prevent the use of protocol features and extensions
> Any proxy can both read and modify plaintext
> Server can't authenticate client at all, client certs are busted  
> forever
> Server can't authenticate proxy at all
> Server probably can't detect proxy downgrade
> Proxy relies on client to stop P-C MitM
> Server relies on proxy to stop S-P MitM
>
>> The client should be able to decide if it
>> accepts the proxy for a particular session, and the scope of the  
>> proxy
>> should be limited, and the proxy should not lie to the client. The
>> client should also have the full information about the server on the
>> other end of the connection.
>
> But by installing the custom root CA in the browser you've weakened  
> the guarantees (which derive from "MUST"s and "MUST NOT"s) to merely  
> "should"s and "should not"s. I.e., you've removed the strong crypto  
> guarantees from the perspective of the legitimate client and (by  
> extension) the server, who are the only parties given any security  
> guarantees at all in the current TLS RFCs.
>
>> We oppose the development of a technology that would help a country  
>> spy
>> on its citizens,and we certainly oppose the development of  
>> standards in
>> that area.
>
> Meh. It already exists for anyone controlling a trusted root or sub- 
> CA, why would they choose to turn on this functionality?
>
>> The IETF can't control how the technologies that it develops
>> are used, or who uses them, of course, which makes it imperative to  
>> not
>> develop any mechanisms that could be used in that way.
>
> Put it another way: don't develop mechanisms that break basic  
> security guarantees. Even better would be to improve on them.
>
> - Marsh