Re: [TLS] TLS Proxy Server Extension
David McGrew <mcgrew@cisco.com> Fri, 29 July 2011 22:24 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 5364B11E80B8 for <tls@ietfa.amsl.com>; Fri, 29 Jul 2011 15:24:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.803
X-Spam-Level:
X-Spam-Status: No, score=-102.803 tagged_above=-999 required=5 tests=[AWL=-0.204, 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 E+fsqSDI8T0F for <tls@ietfa.amsl.com>; Fri, 29 Jul 2011 15:24:11 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A7BDE11E8095 for <tls@ietf.org>; Fri, 29 Jul 2011 15:24:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=1685; q=dns/txt; s=iport; t=1311978251; x=1313187851; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=pwmxsBfayqYoYjerMv07nGWL61ZMuhm5GQ+x9UVc6O4=; b=YCp6CZaeZA5iekNBEWe/NWY2rl6qsXt/e4WQiPiTx46jG48OOCcfpnjN bzxb5Qb0ZEgKYDEe6+mxYhGbWvmA65CcTVlY6fHWlhHhHltDZJI3cgdz6 06+QqIiaOrBSusCxl0P2c03+hAcJ5bVicibWfjvu1vaGWFIx8kfm663v9 s=;
X-IronPort-AV: E=Sophos;i="4.67,289,1309737600"; d="scan'208";a="7938176"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-4.cisco.com with ESMTP; 29 Jul 2011 22:24:11 +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 p6TMO9wM012491; Fri, 29 Jul 2011 22:24:10 GMT
Message-Id: <D142B8F0-3F3C-4D69-918E-C15F42E84CBF@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: mrex@sap.com
In-Reply-To: <201107292044.p6TKinFB022634@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 15:24:09 -0700
References: <201107292044.p6TKinFB022634@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 22:24:16 -0000
On Jul 29, 2011, at 1:44 PM, Martin Rex wrote: > Matt McCutchen wrote: >> >> On Wed, 2011-07-27 at 20:17 +0200, Martin Rex wrote: >>> Only for Web-Browser scenario can I personally see a very limited >>> value that does not amount to 100% wiretapping. >>> >>> Are you aware of rfc2804 "IETF Policy on Wiretapping"? >>> >>> http://tools.ietf.org/html/rfc2804 >>> >>> Standardizing MITM attacks on TLS-protected communication >>> ("lawful intercept?") seems like an extremely bad idea to me. >> >> This is not wiretapping as defined in that policy. > Right, it's clearly not wiretapping as per RFC 2804: "Wiretapping is what occurs when information passed across the Internet from one party to one or more other parties is delivered to a third party: 1. Without the sending party knowing about the third party ..." The intent of the work we are discussing is to ensure that the client knows about the third party. > > I *STRONGLY* disagree. That is very much about wiretapping and > even goes far beyond that, because it not only reveals the content > of the communication, it also allows the "TLS proxy" to arbitrarily > manipulate the communication in a fashion that might be entirely > concealed to the communication peers at the end. > > > I am strongly opposed to have any document describing such proxies > published as an RFC! > And yet you would favor a protocol that propagates decryption keys around the network? We don't have a choice about whether or not TLS proxying will be done on the Internet; it is being done. What we can choose is whether or not the IETF improves how it is being done. David
- [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