Re: [TLS] TLS and middleboxes again

Yaron Sheffer <yaronf.ietf@gmail.com> Wed, 31 August 2011 19:37 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 CC17B21F8F57 for <tls@ietfa.amsl.com>; Wed, 31 Aug 2011 12:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.505
X-Spam-Level:
X-Spam-Status: No, score=-103.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 wxEbJPMXPl8y for <tls@ietfa.amsl.com>; Wed, 31 Aug 2011 12:37:44 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id AB5A521F8F35 for <tls@ietf.org>; Wed, 31 Aug 2011 12:37:43 -0700 (PDT)
Received: by ewy19 with SMTP id 19so746097ewy.31 for <tls@ietf.org>; Wed, 31 Aug 2011 12:39: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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Y8Q3PX26Cc4rfCWayucIBYFSx2jkLBmmH8ubXcoeivY=; b=SUY/tW58cPBFYZarQgxNEAO7B96hZlVbWoRJmZyQodlDGDM1u7eGyOq9P5/mjibrx5 IUfSyRRehqQFsuXpz/dtAathGZc113tq0XwLS08mxGIdEtg8WfPoQO3Oz5w03XfrTDbG YXdAt7bkya0ZIpOyVUzrn9CnOYvQUTBVQeXRw=
Received: by 10.213.108.131 with SMTP id f3mr487677ebp.16.1314819553958; Wed, 31 Aug 2011 12:39:13 -0700 (PDT)
Received: from [10.0.0.3] (bzq-79-181-242-252.red.bezeqint.net [79.181.242.252]) by mx.google.com with ESMTPS id 35sm4978830eex.15.2011.08.31.12.39.11 (version=SSLv3 cipher=OTHER); Wed, 31 Aug 2011 12:39:13 -0700 (PDT)
Message-ID: <4E5E8DD9.40604@gmail.com>
Date: Wed, 31 Aug 2011 22:39:05 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: tls@ietf.org
References: <mailman.94.1314817212.4828.tls@ietf.org>
In-Reply-To: <mailman.94.1314817212.4828.tls@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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, 31 Aug 2011 19:37:44 -0000

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.

Thanks,
     Yaron

On 31.8.2011 22:00, tls-request@ietf.org wrote:
> Date: Wed, 31 Aug 2011 14:57:51 +0300
> From: Yoav Nir<ynir@checkpoint.com>
> To: Chris Richardson<chris@randomnonce.org>
> Cc: "tls@ietf.org List"<tls@ietf.org>
> Subject: Re: [TLS] TLS and middleboxes again
> Message-ID:<0AD45ACF-20DA-474B-BEB8-ECAF7AC2EBF3@checkpoint.com>
> Content-Type: text/plain; charset="us-ascii"
>
> The middlebox would still have to at least delay application records until the keys are delivered. Also, making sure that the keys are actually delivered to the middlebox reliably is extremely hard unless we use the existing connection.
>
> I just don't see an out-of-band delivery as being workable.
>
> If we could eliminate the records that the middlebox inserts, and have only the client and server send records, I agree that it would be better, but without the middlebox announcing its presence, I don't see how the protocol could work without too much key sharing. I'll be glad to get some suggestions.
>
> Yoav
>
> On Aug 30, 2011, at 5:58 PM, Chris Richardson wrote:
>
>> If the middlebox is inserting KeyShareInfo records into the stream,
>> then it must modify the TCP sequence number on all future packets in
>> the handshake.  One cannot use a "dumb" middlebox that modifies the
>> handshakes and nothing more.
>>
>> Perhaps an out-of-band keysharing mechanism would be better.
>>
>> On Thu, Aug 25, 2011 at 3:39 AM, Yoav Nir<ynir@checkpoint.com>  wrote:
>>> Hi all
>>>
>>> Several weeks ago, Dave McGrew submitted a draft for improving the workings of TLS proxies. As expected, this generated a lot of controversy, with some people saying that they'd rather hand over the session keys to the middlebox than to standardize a MitM attack.
>>>
>>> I was on the other side of that debate, but one problem with comparing the two alternatives is that for proxies there are several commercial products and Dave's draft, while there's nothing for key sharing. To remedy that, and help the discussion along, I've submitted the below draft. Comments and additional controversy are very welcome.
>>>
>>> Yoav
>>>
>
>
> ------------------------------
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
> End of TLS Digest, Vol 85, Issue 22
> ***********************************