IETF Logo Mail Archive

Re: [TLS] New draft for "next protocol"

Adam Langley <agl@google.com> Sun, 29 May 2011 14:18 UTC

Return-Path: <agl@google.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 5904EE06F5 for <tls@ietfa.amsl.com>; Sun, 29 May 2011 07:18:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level:
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tZG6aAPGr2u for <tls@ietfa.amsl.com>; Sun, 29 May 2011 07:18:00 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6639AE0662 for <tls@ietf.org>; Sun, 29 May 2011 07:18:00 -0700 (PDT)
Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p4TEHw0t007378 for <tls@ietf.org>; Sun, 29 May 2011 07:17:59 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306678679; bh=jjF6CO5wE7Y52ioPwvrM023js0k=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=guFCkFUoTif+v1VQrVKrJBNQTzNU+QQ0853bdtmo+Rc++q+5w1C6dP+CHz9Lr0gz4 dqdAypbdp+bF8hWIAvQBw==
Received: from gyh20 (gyh20.prod.google.com [10.243.50.212]) by kpbe18.cbf.corp.google.com with ESMTP id p4TEHu2Z007937 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <tls@ietf.org>; Sun, 29 May 2011 07:17:57 -0700
Received: by gyh20 with SMTP id 20so1904953gyh.22 for <tls@ietf.org>; Sun, 29 May 2011 07:17:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ViFMlddKAM2E7vFGRzvh6X1623liAW5QxJmPMFH/mOg=; b=bHbS3cYKRT41b3UdukR+sD45vSI8BjRXrdK6tTkcS/OrOj/PE4fronIK2hugO2+6qz B6jWRhNuhXevRrYXx7gQ==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Xi/LHMmCQIX53HNqAj8GqP81ypCh/vWuRi0qws0/hS4FdJKbmAPQcYygT58YM4QK49 9QySOgy/7VPkldg+VQbA==
MIME-Version: 1.0
Received: by 10.151.154.8 with SMTP id g8mr3651188ybo.29.1306678676810; Sun, 29 May 2011 07:17:56 -0700 (PDT)
Received: by 10.150.177.1 with HTTP; Sun, 29 May 2011 07:17:56 -0700 (PDT)
In-Reply-To: <1306427380.4099.18.camel@localhost>
References: <24ADE5FF-FDEE-493E-A00A-F6C5F274A7C3@vpnc.org> <4851D6E10A7F63448F4B32C3E2814AC91772C79D@SEAEMBX02.olympus.F5Net.com> <BANLkTi=4H0kOK-tw79FR5yEzVhuhwZy6eA@mail.gmail.com> <1306427380.4099.18.camel@localhost>
Date: Sun, 29 May 2011 10:17:56 -0400
Message-ID: <BANLkTikz_Nkc1Vhxz7j9bx738FS0HAw1Pw@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Matt McCutchen <matt@mattmccutchen.net>
Content-Type: text/plain; charset="UTF-8"
X-System-Of-Record: true
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] New draft for "next protocol"
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: Sun, 29 May 2011 14:18:01 -0000

On Thu, May 26, 2011 at 12:29 PM, Matt McCutchen <matt@mattmccutchen.net> wrote:
> And when the firewalls start filtering based on the NPN extension, we
> will be back to square one.

Firewalls could filter on a) the presence of nextproto in the
ClientHello or b) the protocols in the ServerHello. Since Chrome
already sends the nextproto extension, filtering that is hopefully too
destructive. b) might become an issue, but that's why the client is
free to pick a protocol that wasn't advertised by the server if it has
out-of-band knowledge that the server will support it. The client's
choice is deliberately sent under encryption and in constant space in
order to protect it from filtering.


AGL

v2.23.0 | Report a Bug | By Email