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
- [TLS] Next protocol negotiation Adam Langley
- [TLS] Next protocol negotiation Adam Langley
- Re: [TLS] Next protocol negotiation Nikos Mavrogiannopoulos
- Re: [TLS] Next protocol negotiation Adam Langley
- Re: [TLS] Next protocol negotiation Nikos Mavrogiannopoulos
- Re: [TLS] Next protocol negotiation Adam Langley
- Re: [TLS] Next protocol negotiation Marsh Ray
- Re: [TLS] Next protocol negotiation Steve Dispensa
- Re: [TLS] Next protocol negotiation Adam Langley
- Re: [TLS] Next protocol negotiation Marsh Ray
- Re: [TLS] Next protocol negotiation Yoav Nir
- Re: [TLS] Next protocol negotiation Yoav Nir
- Re: [TLS] Next protocol negotiation Yoav Nir
- Re: [TLS] Next protocol negotiation Marsh Ray
- Re: [TLS] Next protocol negotiation Adam Langley
- Re: [TLS] Next protocol negotiation Adam Langley
- Re: [TLS] Next protocol negotiation Dean Anderson
- Re: [TLS] Next protocol negotiation Adam Langley
- Re: [TLS] Next protocol negotiation Dean Anderson
- Re: [TLS] Next protocol negotiation Adam Langley