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 > ***********************************
- 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