Re: [TLS] TLS Proxy Server Extension

David McGrew <mcgrew@cisco.com> Fri, 29 July 2011 19:33 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 1D8985E8011 for <tls@ietfa.amsl.com>; Fri, 29 Jul 2011 12:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.858
X-Spam-Level:
X-Spam-Status: No, score=-102.858 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, 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 8d-C4SEpfuLL for <tls@ietfa.amsl.com>; Fri, 29 Jul 2011 12:33:42 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D84315E801D for <tls@ietf.org>; Fri, 29 Jul 2011 12:33:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=1839; q=dns/txt; s=iport; t=1311968014; x=1313177614; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=giZuAUJZP4UG6Ouk2ydZrw5APcMt57sevlVOJTyFrug=; b=V5MS1HP2+yKlv0Inn47mWX+AYyp6Wm/ZliJHLcu7T9MuOsaXjBb2mcl/ fBDtbFBtG7AtgvwTLKnN+KGKwu4pFdlA1tQ02PYUjQXPz0eiyBt+ebmUz tkNjcV/NCL5Bd7t/AhS1cTasVW9XnxNUX4EhAc1Nqi3sNFzoVUhE+r9c3 o=;
X-IronPort-AV: E=Sophos;i="4.67,288,1309737600"; d="scan'208";a="7896042"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-2.cisco.com with ESMTP; 29 Jul 2011 19:33:33 +0000
Received: from stealth-10-32-254-214.cisco.com (stealth-10-32-254-214.cisco.com [10.32.254.214]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6TJWlBQ023800; Fri, 29 Jul 2011 19:33:32 GMT
Message-Id: <A67FAF78-F8FA-41BA-8CC1-B26CB8509155@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: mrex@sap.com
In-Reply-To: <201107290621.p6T6Lckb004132@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 29 Jul 2011 12:33:31 -0700
References: <201107290621.p6T6Lckb004132@fs4113.wdf.sap.corp>
X-Mailer: Apple Mail (2.936)
Cc: tls@ietf.org, pgladstone@cisco.com
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: Fri, 29 Jul 2011 19:33:43 -0000

Hi Martin,

On Jul 28, 2011, at 11:21 PM, Martin Rex wrote:

> Matt McCutchen wrote:
>>
>>> and that also enables the clients
>>> to clearly limit who is able to read the traffic.
>>
>> Huh?  The proxy's ability to pass decrypted data to someone else is  
>> no
>> different than if it were bridging two TLS connections.
>
> No, that is entirely different.
>
> Revealing the traffic **encryption** keys to the proxy requires  
> cooperation
> of the client, so a sensible client implementation can ask for consent
> and the user may deny consent, whereas a proxy with a super-CA-cert
> can subvert any connection for that client, no matter where that
> client goes--and MitM all connections any time, including those that  
> do
> not traverse that proxy.

It sounds like you misunderstand the proposal.  The approach we are  
going for is one in which the client is fully informed about both the  
proxy and the server, and the client is free to choose to trust them  
or not.

>
>
>>
>>> No super-CA-equivalent
>>> keys would need to be on the malware-scanning Proxy.
>>
>> You speak as if that were in a whole different class of badness,  
>> but the
>> actual effect is simply to give up integrity as well as  
>> confidentiality
>> to the proxy.
>
> You would not reveal the MAC keys, of course. only the encryption  
> keys.
>
> There is no need to allow the proxy to modify the traffic.  If the
> proxy doesn't like some of the data, it should not pass it along and
> terminate the connection.
>
> -Martin

No, this undermines the cryptographic security.  Please see Section 6  
of the draft.

A malware-screening proxy needs to be able to modify the traffic  
flowing through it.  It would be pointless for it to detect malware,  
and then pass it on to the client!

David