Re: [TLS] TLS and middleboxes again

Yaron Sheffer <yaronf.ietf@gmail.com> Thu, 01 September 2011 07:01 UTC

Return-Path: <yaronf.ietf@gmail.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 5322F21F87D6 for <tls@ietfa.amsl.com>; Thu, 1 Sep 2011 00:01:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 AqS3QqjOzpxr for <tls@ietfa.amsl.com>; Thu, 1 Sep 2011 00:01:42 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 52FF021F87C9 for <tls@ietf.org>; Thu, 1 Sep 2011 00:01:42 -0700 (PDT)
Received: by wyg8 with SMTP id 8so1250610wyg.31 for <tls@ietf.org>; Thu, 01 Sep 2011 00:03:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xM1cIYZXs/101vs4FNcNGjnt0l0wU2KrPz7IJrFeQ2g=; b=LJ8iZm6/IJRTgZQIva8xuSHGuFc6lxRJtAjLUhLXnIzoi1PPX2XXDZ7pz2vKgjfKBl 9fSFCggEY7PkkyIITfa1Kub04gVyaWEX/sFxoJsHZA1AKme7vqiiZhqy5ScEIw3P0NvP XJprOxRUg+fp0FUi6suLRsyRr2qbGHwo2GOMc=
Received: by 10.227.28.4 with SMTP id k4mr1239975wbc.21.1314860593879; Thu, 01 Sep 2011 00:03:13 -0700 (PDT)
Received: from [10.0.0.6] (93-172-1-150.bb.netvision.net.il [93.172.1.150]) by mx.google.com with ESMTPS id fy13sm250530wbb.5.2011.09.01.00.03.12 (version=SSLv3 cipher=OTHER); Thu, 01 Sep 2011 00:03:13 -0700 (PDT)
Message-ID: <4E5F2E2E.2020803@gmail.com>
Date: Thu, 01 Sep 2011 10:03:10 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>
References: <mailman.94.1314817212.4828.tls@ietf.org> <4E5E8DD9.40604@gmail.com> <395BFC9B-5B8C-431A-A09A-922C1C088422@checkpoint.com>
In-Reply-To: <395BFC9B-5B8C-431A-A09A-922C1C088422@checkpoint.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
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 07:01:43 -0000

DNS is not crossing any protocol layers, but I agree your proposal is 
simpler.

Adding a time-to-live to the alert/announcement (with e.g. max 1 hour) 
would probably solve the problem.

     Yaron

On 09/01/2011 09:07 AM, Yoav Nir wrote:
> 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.
>