IETF Logo Mail Archive

Re: [TLS] Confirming consensus for ALPN

Juho Vähä-Herttua <juhovh@iki.fi> Fri, 15 March 2013 23:02 UTC

Return-Path: <juhovh@iki.fi>
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 6964D21F86EF for <tls@ietfa.amsl.com>; Fri, 15 Mar 2013 16:02:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.902
X-Spam-Level:
X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hbk8qut1Op1U for <tls@ietfa.amsl.com>; Fri, 15 Mar 2013 16:02:20 -0700 (PDT)
Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id A07F621F84A1 for <tls@ietf.org>; Fri, 15 Mar 2013 16:02:18 -0700 (PDT)
Received: from [10.48.50.76] (188.238.51.76) by jenni2.inet.fi (8.5.140.03) id 50871399093F4D6F; Sat, 16 Mar 2013 01:02:16 +0200
References: <CABcZeBOFkcW6XvFqWivn4+WSac727iNVQYBumRBmagwBRv1UXg@mail.gmail.com> <CAOhHAXyNoVT=qx=eVKWVjn=49zAPrRTBr9377j7nxoWb8JfN5g@mail.gmail.com> <D9DF65C6-853E-473A-9450-4636784DF96B@iki.fi> <CAOhHAXxi8SSxLZfg43qyAW7m36+q9sP7BdZ4mqgNeBH7WK1Yuw@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CAOhHAXxi8SSxLZfg43qyAW7m36+q9sP7BdZ4mqgNeBH7WK1Yuw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-5B788E8C-CB41-4E78-B799-7BF186C62606"
Content-Transfer-Encoding: 7bit
Message-Id: <11AF66DA-69ED-49E9-8D93-7CCC06AF624D@iki.fi>
X-Mailer: iPhone Mail (10B146)
From: Juho Vähä-Herttua <juhovh@iki.fi>
Date: Sat, 16 Mar 2013 01:02:14 +0200
To: Mohamad Badra <mbadra@gmail.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Confirming consensus for ALPN
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: Fri, 15 Mar 2013 23:02:20 -0000

On 16.3.2013, at 0.41, Mohamad Badra <mbadra@gmail.com> wrote:
> On Sat, Mar 16, 2013 at 2:31 AM, Juho Vähä-Herttua <juhovh@iki.fi> wrote:
>> The discussion here might have been a bit misleading recently. My understanding is that the main goal of ALPN is the same as with NPN: allowing the use of "next-gen" HTTP versions (mainly SPDY and HTTP/2) on the same port as HTTPS, because they serve the same content anyway. So (b) would be closer.
> 
> But HTTP allows version negotiation, why should be this brought to the TLS level?

SPDY usually serves HTTP content, but it is not HTTP compatible on the wire. This means HTTP version negotiation is not relevant in that case. And as Nico already said, negotiating the version on TLS level saves one extra round trip, which speeds up things.


Juho

v2.23.0 | Report a Bug | By Email