IETF Logo Mail Archive

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

Adam Langley <agl@google.com> Wed, 18 May 2011 20:06 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 212A0E0778 for <tls@ietfa.amsl.com>; Wed, 18 May 2011 13:06:39 -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 cYp+QMRZfPKQ for <tls@ietfa.amsl.com>; Wed, 18 May 2011 13:06:38 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6C83DE0773 for <tls@ietf.org>; Wed, 18 May 2011 13:06:38 -0700 (PDT)
Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p4IK6awP016202 for <tls@ietf.org>; Wed, 18 May 2011 13:06:37 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1305749197; bh=2P+QytTBs31UZt1tmfCrJ6VNHaQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=ZMzo12ssEJvaw0kqiBgGENgyCZCC6cj3vul1mb7vQ/YDtoG/e6bAnztvEUZFS12OS t81WJaXwbJI+sZFV+S1Hw==
Received: from yxe42 (yxe42.prod.google.com [10.190.2.42]) by kpbe19.cbf.corp.google.com with ESMTP id p4IK4lli026409 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <tls@ietf.org>; Wed, 18 May 2011 13:06:35 -0700
Received: by yxe42 with SMTP id 42so952482yxe.16 for <tls@ietf.org>; Wed, 18 May 2011 13:06:35 -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 :content-transfer-encoding; bh=poh0TJgmDlemlcoDXTsUMWrOLDna05jst0wmndHdgJw=; b=G7R84+yplGja4Ma3ZtKYqqyZaZr8KKWgsuCBgI5I4uUjsiUaptm/zlecMe5qKRJgk4 OL86LhNAvfpp8qDG+a4w==
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:content-transfer-encoding; b=iaD3GRnCc34dFBbe12iGjxJa9c/L6t5IEaOMkEnOROyTZ6DwBKZ5HyglXlM8B/5MDz mGGcDz5OzPyTiGnK4Xgg==
MIME-Version: 1.0
Received: by 10.150.48.28 with SMTP id v28mr1915183ybv.428.1305749195454; Wed, 18 May 2011 13:06:35 -0700 (PDT)
Received: by 10.150.177.1 with HTTP; Wed, 18 May 2011 13:06:35 -0700 (PDT)
In-Reply-To: <4851D6E10A7F63448F4B32C3E2814AC91772C79D@SEAEMBX02.olympus.F5Net.com>
References: <24ADE5FF-FDEE-493E-A00A-F6C5F274A7C3@vpnc.org> <4851D6E10A7F63448F4B32C3E2814AC91772C79D@SEAEMBX02.olympus.F5Net.com>
Date: Wed, 18 May 2011 13:06:35 -0700
Message-ID: <BANLkTi=4H0kOK-tw79FR5yEzVhuhwZy6eA@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: David Holmes <d.holmes@f5.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "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: Wed, 18 May 2011 20:06:39 -0000

On Sun, May 15, 2011 at 8:45 PM, David Holmes <d.holmes@f5.com> wrote:
> Can you describe in more detail how the extension works against an attacker?  And let me apologize if this has already been discussed, I don't remember seeing it on the mailing list.

Preventing cross-protocol attacks is one of several uses for NPN,
although it is the one that is currently most highlighted in the
draft.

Previous versions of the websockets protocol have had to be
reverted[1] because of cross-protocol attacks where an attacker
creates confusion about which protocol is being used. As network
transparency issues force many other protocols to support running over
port 443 the risk of something bad resulting from the n^2 possible
confusions keeps going up.

NPN simply allows a client to state, unambiguously, which protocol is
being spoken.

[1] http://www.ietf.org/mail-archive/web/hybi/current/msg04744.html


Cheers

AGL

v2.23.0 | Report a Bug | By Email