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