Re: [TLS] TLS and middleboxes again

Yoav Nir <ynir@checkpoint.com> Thu, 01 September 2011 06:05 UTC

Return-Path: <ynir@checkpoint.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 7A55D21F8B31 for <tls@ietfa.amsl.com>; Wed, 31 Aug 2011 23:05:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.374
X-Spam-Level:
X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 mVwRmu8CMNm4 for <tls@ietfa.amsl.com>; Wed, 31 Aug 2011 23:05:51 -0700 (PDT)
Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7F85021F8B30 for <tls@ietf.org>; Wed, 31 Aug 2011 23:05:50 -0700 (PDT)
X-CheckPoint: {4E5F2E5C-2-1B221DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p8167I8q005106; Thu, 1 Sep 2011 09:07:18 +0300
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 1 Sep 2011 09:07:19 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Date: Thu, 1 Sep 2011 09:07:16 +0300
Thread-Topic: [TLS] TLS and middleboxes again
Thread-Index: AcxobWdh53mKB7EGSSiKsUveMyP/7A==
Message-ID: <395BFC9B-5B8C-431A-A09A-922C1C088422@checkpoint.com>
References: <mailman.94.1314817212.4828.tls@ietf.org> <4E5E8DD9.40604@gmail.com>
In-Reply-To: <4E5E8DD9.40604@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
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: Thu, 01 Sep 2011 06:05:51 -0000

On Aug 31, 2011, at 10:39 PM, Yaron Sheffer wrote:

> Here's a suggestion to avoid the records that announce the proxy. It's 
> not ideal, but it may be easier to implement/deploy than an intrusive proxy.
> 
> We could use some sort of discovery mechanism to detect the presence of 
> the proxy. Then the client queries the proxy for its certificate hash 
> (with a well known URL), and you can assume the proxy will in fact be 
> there. The discovery process itself is *not* security-sensitive, and we 
> can use caching.
> 
> Two options are PAC (http://en.wikipedia.org/wiki/Proxy_auto-config and 
> http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol) and DNS 
> SRV records. The former is commonly deployed in enterprises, the latter 
> is much simpler to standardize and implement, and architecturally cleaner.
> 

All these involve a potentially lengthy discovery process, and more inter-layer communications than I'd like. 

The common use case for a middlebox is for when I'm "inside" the company perimeter. In the place where I work, there's WLAN reception on all floors, but none in the stairwell. Going upstairs with a smartphone involves roaming from the WLAN to the 3G network and back to the WLAN. As far as the middlebox is concerned, you're going from "inside" to "outside" and back "inside".

There is an obvious way for discovery: the client sends hashes of the middlebox certificates in the extension. If the middlebox hash is missing, the middlebox will interfere by sending an alert with its hash and a URL for getting its certificate. The harder question is how to discover that the proxy is gone (or rather, off-path). It's not quite as important, because sending encrypted keys to a non-existant middlebox should not cause a lot of damage, but we don't want to keep accumulating middleboxes.