Re: [TLS] Next protocol negotiation

Adam Langley <agl@google.com> Thu, 21 January 2010 16:49 UTC

Return-Path: <agl@google.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E6F3A68D9 for <tls@core3.amsl.com>; Thu, 21 Jan 2010 08:49:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.177
X-Spam-Level:
X-Spam-Status: No, score=-104.177 tagged_above=-999 required=5 tests=[AWL=-2.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7Lm8bgPqeSi for <tls@core3.amsl.com>; Thu, 21 Jan 2010 08:49:36 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 6E9553A6878 for <tls@ietf.org>; Thu, 21 Jan 2010 08:49:36 -0800 (PST)
Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id o0LGnVHr015803 for <tls@ietf.org>; Thu, 21 Jan 2010 08:49:31 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1264092571; bh=sk11Nr9tMIanhbCJO69LGPaadk4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=yLbNas5TSw/V5AM8rUFCrngXszXq+8wP3935vX1+xwauuTlCaQjHLaPTwhOx0Fj75 ctvGyA6T/ivkfdewwqGcw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=hQX+1XQTRA13e48lca2qDIC3VcHtIXJKK8A1Q294XFbYsH2CL63/NyrLF9GtPnfpe /XHzSCCCI5LishphVVv1g==
Received: from pzk41 (pzk41.prod.google.com [10.243.19.169]) by wpaz1.hot.corp.google.com with ESMTP id o0LGnUwt030472 for <tls@ietf.org>; Thu, 21 Jan 2010 08:49:30 -0800
Received: by pzk41 with SMTP id 41so206770pzk.0 for <tls@ietf.org>; Thu, 21 Jan 2010 08:49:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.143.20.40 with SMTP id x40mr1148424wfi.226.1264092570029; Thu, 21 Jan 2010 08:49:30 -0800 (PST)
In-Reply-To: <4B580E0A.2070104@extendedsubset.com>
References: <a84d7bc61001200520t4e3be7d4sb0bb614abb0b5e4e@mail.gmail.com> <c331d99a1001200646o55d7d2f6wfaad058b84e6024e@mail.gmail.com> <a84d7bc61001200705v39b37ba3qaea1ca4149afb0a0@mail.gmail.com> <4B5723A5.8050508@gnutls.org> <a84d7bc61001200757p30ffded4y8b0f34b157fa4dc4@mail.gmail.com> <4B572EA6.8040902@extendedsubset.com> <a84d7bc61001200852p18ca82e4me4214661d7b0be9b@mail.gmail.com> <D4AEE85C-64FD-4F92-88F2-5C7BE82CEF74@checkpoint.com> <4B580E0A.2070104@extendedsubset.com>
Date: Thu, 21 Jan 2010 08:49:29 -0800
Message-ID: <a84d7bc61001210849o79b44c8bh6feb255683b002bc@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Marsh Ray <marsh@extendedsubset.com>
Content-Type: text/plain; charset=UTF-8
X-System-Of-Record: true
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Next protocol negotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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, 21 Jan 2010 16:49:37 -0000

On Thu, Jan 21, 2010 at 12:19 AM, Marsh Ray <marsh@extendedsubset.com>; wrote:
> 2. If this is true, what depth of inspection is necessary to provide
> security? Is it destined to grow ever deeper? Semantic web indeed!

Inspection of network traffic, even if TLS connections are unwrapped,
cannot stop a determined attacker. There will always be large amounts
of side channel capacity in anything resembling a web capable
connection.

But I don't believe that this is the threat model of these middleware
boxes. In my experience they generally want to implement caching,
virus scanning or blocking of casual users. The caching issue is an
interesting one and we welcome development in this area. But these
must be implemented in a manner that doesn't result in the continual
ossification of the Internet. By being implicit and undocumented they
force a continuous retreat to the least common denominator in the hope
most of them will pass simple traffic most of the time. This probably
means that the network is not the place for them and that one should
focus on client side changes and explicit configuration of proxy
servers.

The development of TLS intercepting proxies is saddening. Thankfully I
believe that they are currently fairly limited. In the interests of
future development, measures should probably be taken to ensure that
they remain so. (In this point I am not representing my employer: to
my knowledge we've no official position on this.) For example, Chrome
could require that certificates for Google sites always be rooted at
Thawte for the lifetime of the current certificates. When considering
various issues with the CA ecosystem in the past couple of years, this
might also have a desirable security benefit.


AGL