Re: [TLS] TLS and middleboxes again
Philip Gladstone <pgladstone@cisco.com> Wed, 07 September 2011 12:28 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 5824821F8C33 for <tls@ietfa.amsl.com>; Wed, 7 Sep 2011 05:28:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.948
X-Spam-Level:
X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dMPWCym5ZNl for <tls@ietfa.amsl.com>; Wed, 7 Sep 2011 05:28:20 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BBECB21F8C09 for <tls@ietf.org>; Wed, 7 Sep 2011 05:28:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=8694; q=dns/txt; s=iport; t=1315398609; x=1316608209; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=HIzwVu/9e2ZtG++DWCJ27xjym/8CCRMTuzNhoPmHR4k=; b=LsRRT03km3SfXAz/TKx5Nb7UzBF6BFgkYNHRQe79KZ+w3oQv2Hz9Cm+6 ScN9C4xpuVs6Go/a//PyjkeWTOcm+i4Df9ymoDs60ZTp60sVQbHeMh3R3 feX5VRivd5im+Pf911EwygexWIBd0+5OrnG0gwsclCPSxd48cUWBiKA7O 8=;
X-Files: smime.p7s : 4899
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmgHAC1jZ06tJV2d/2dsb2JhbABAA4RVlFOOQniBRgEBAQEDEgEQVQ8CCxgJFgsCAgIHAwIBAgEJPBADBgIBAR6gagGMN5IYAoNdgXuBEQSOJ4ULhRKMHw
X-IronPort-AV: E=Sophos; i="4.68,345,1312156800"; d="p7s'?scan'208"; a="19747754"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 07 Sep 2011 12:30:09 +0000
Received: from [161.44.106.139] (dhcp-161-44-106-139.cisco.com [161.44.106.139]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p87CU8I6001884 for <tls@ietf.org>; Wed, 7 Sep 2011 12:30:08 GMT
Message-ID: <4E6763CF.7070802@cisco.com>
Date: Wed, 07 Sep 2011 08:30:07 -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: <mailman.69.1314385218.21832.tls@ietf.org> <4E57FC4B.3080809@gmail.com> <4E5805EC.6000904@fifthhorseman.net>
In-Reply-To: <4E5805EC.6000904@fifthhorseman.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms030704030505030209050103"
Subject: Re: [TLS] TLS and middleboxes again
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, 07 Sep 2011 12:28:20 -0000
On 8/26/2011 4:45 PM, Daniel Kahn Gillmor wrote: > Since HTTP redirects can only be done in an HTTP header, the middlebox > would need to buffer all HTTP content before relaying it to the User > Agent, in case "bad" material was found at the end. > > I don't think either of these use cases are valuable, certainly not > valuable enough to warrant allowing middleboxes to violate the integrity > guarantees of TLS. > > The problem with not allowing modification of the data stream is that the middlebox only has one choice left -- to abort the connection. This provides a less than satisfactory experience to the end user -- and some file transfer managers will simply retry the connection (as they think that the connection was accidentally aborted). There is another reason to release the authentication keys -- and that is to prove to the middlebox that the correct encryption key was released. Otherwise, the client can release a bogus encryption key, and the middlebox has no way of determining what is being transferred. [Of course, the client would release the correct key initially to cover the HTTP request, and would then rekey the connection with the server and release an incorrect key for the response body. ] Philip -- Philip Gladstone Distinguished Engineer Product Development pgladstone@cisco.com Phone: +1 978-ZEN-TOAD (+1 978 936 8623) Google: +1 978 800 1010 Ham radio: N1DQ
- Re: [TLS] TLS and middleboxes again Michael D'Errico
- [TLS] TLS and middleboxes again Yoav Nir
- Re: [TLS] TLS and middleboxes again Yaron Sheffer
- Re: [TLS] TLS and middleboxes again Juho Vähä-Herttua
- Re: [TLS] TLS and middleboxes again Nikos Mavrogiannopoulos
- Re: [TLS] TLS and middleboxes again Blumenthal, Uri - 0668 - MITLL
- Re: [TLS] TLS and middleboxes again Yaron Sheffer
- Re: [TLS] TLS and middleboxes again Yoav Nir
- Re: [TLS] TLS and middleboxes again Yoav Nir
- Re: [TLS] TLS and middleboxes again Daniel Kahn Gillmor
- Re: [TLS] TLS and middleboxes again Blumenthal, Uri - 0668 - MITLL
- Re: [TLS] TLS and middleboxes again Chris Richardson
- Re: [TLS] TLS and middleboxes again Yoav Nir
- Re: [TLS] TLS and middleboxes again Yaron Sheffer
- Re: [TLS] TLS and middleboxes again Yoav Nir
- Re: [TLS] TLS and middleboxes again Yaron Sheffer
- Re: [TLS] TLS and middleboxes again Philip Gladstone