Re: [TLS] Next protocol negotiation
Adam Langley <agl@google.com> Wed, 20 January 2010 16:52 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 D08823A6837 for <tls@core3.amsl.com>; Wed, 20 Jan 2010 08:52:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.31
X-Spam-Level:
X-Spam-Status: No, score=-106.31 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 BZtg2Qpzh-lL for <tls@core3.amsl.com>; Wed, 20 Jan 2010 08:52:41 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 939383A6823 for <tls@ietf.org>; Wed, 20 Jan 2010 08:52:40 -0800 (PST)
Received: from spaceape24.eur.corp.google.com (spaceape24.eur.corp.google.com [172.28.16.76]) by smtp-out.google.com with ESMTP id o0KGqZDd015603 for <tls@ietf.org>; Wed, 20 Jan 2010 16:52:35 GMT
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1264006355; bh=zIu5DvuTawucP0rufBQz2Q7JxMY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=bUCkNtSFa3KBcSx2lemhaFT5TIcsPcu3GBAbP3xuXsm5s0xMHOMJRUnObQZGnyffR eAGLPRLnqjdwUHdhJYjmQ==
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=VVL8dNDa/3bFkLFb9I0icpBUj0k+75vAdRXFEjHvpKVqjYVveunTVLLDOCuBwIS3P 94rUkDKangxsvNGwKb7Zg==
Received: from pxi41 (pxi41.prod.google.com [10.243.27.41]) by spaceape24.eur.corp.google.com with ESMTP id o0KGqXLo020889 for <tls@ietf.org>; Wed, 20 Jan 2010 08:52:34 -0800
Received: by pxi41 with SMTP id 41so4097315pxi.27 for <tls@ietf.org>; Wed, 20 Jan 2010 08:52:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.142.56.9 with SMTP id e9mr156984wfa.62.1264006352867; Wed, 20 Jan 2010 08:52:32 -0800 (PST)
In-Reply-To: <4B572EA6.8040902@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>
Date: Wed, 20 Jan 2010 08:52:32 -0800
Message-ID: <a84d7bc61001200852p18ca82e4me4214661d7b0be9b@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
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: Wed, 20 Jan 2010 16:52:42 -0000
On Wed, Jan 20, 2010 at 8:26 AM, Marsh Ray <marsh@extendedsubset.com> wrote: > Adam Langley wrote: > One point of view is that firewall admins are ports because of their > intentional policies and it is their right to control what goes on on > their own network. Port 443 is going to be less useful over time as more > sites deploy SSL-inspecting proxies. Organisations that deploy intercepting proxies and port blocking middleware (etc) have reasonable policy goals that they are trying to implement. These people, for the most part, are not bad nor evil. But one cannot expect them to understand the value of the end-to-end principle. They are evaluating different solutions and balancing cost and utility, as it effects them. It turns out that many of them end up choosing networking hardware for caching, virus-scanning, content control etc. These network based solutions can be cheap, but they achieve these cost reductions, in part, by imposing negative externalities on the rest of the world. It's the case these days that HTTP traffic will usually be 'transparently' intercepted at least once. DNS traffic is likewise adulterated, as are many other protocols. Because of this, protocol advances are delayed or lost. (HTTP pipelining is one example, there are many others including our own SDCH[1]). Unfortunately, these losses to the world are non-obvious to many and hard to measure. TLS is attractive because it is obviously much more resistant to these machinations. (I'm aware that such devices do exist to intercept SSL, but they should hopefully be intrinsically more limited.) I admit that by using TLS we are bypassing (preferably) these middleware boxes. Because of this, the cost/benefit analysis of these boxes will hopefully shift so that people start to look for other solutions. We know that we'll have to provide alternatives, but these can be designed so as not to consign the public Internet to slow stagnation at the bottom of the protocol stack. [1] http://en.oreilly.com/velocity2008/public/schedule/detail/2598 > Port 443 to a proxy server with the CONNECT verb usually works. > > It is rumored that many firewalls will pass anything over port 53. > > On many corporate Windows PCs, the 'proxy server' info available in the > registry is the only reliable way to make outbound connections. Port 53 is not as clean as one might hope. CONNECT and port 443 often works, but then we have the same issue as we currently face: how to disambiguate protocols when the TCP port mechanism is unavailable. Next protocol negotiation is our proposed solution. > Thank you guys for caring about 200ms of my finite lifetime. You're welcome although, as noted, the actual delay usually ends up being several multiples for web pages as subresource discovery is slowed down for other domains. 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