IETF Logo Mail Archive

Re: [TLS] Confirming consensus for ALPN

Mohamad Badra <mbadra@gmail.com> Fri, 15 March 2013 23:01 UTC

Return-Path: <mbadra@gmail.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 4F7D121F86BA for <tls@ietfa.amsl.com>; Fri, 15 Mar 2013 16:01:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 lYi5UxFmkGMT for <tls@ietfa.amsl.com>; Fri, 15 Mar 2013 16:01:57 -0700 (PDT)
Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id A818C21F84A1 for <tls@ietf.org>; Fri, 15 Mar 2013 16:01:57 -0700 (PDT)
Received: by mail-vc0-f170.google.com with SMTP id lf10so1660708vcb.1 for <tls@ietf.org>; Fri, 15 Mar 2013 16:01:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xmg7AmMEsAns+Gr+KqQ9kUA2ukn+RfSKBWpNAL8rj1U=; b=X5RoOJ+yHmndEA/gzqcyC2WFvMVBRf7ByjPGpWUT3kHzAQyMJTq8WLsHyXkQJhRANQ As6IbQRpvg/5dOQYIw5nOJ9Wb/24Iaem2TjXvH7fgNyXzQgeC0SymG7fqA/lRrF0EYPL MiVS4SU2i3xN0DDuqkmS77NS6OjV49u2BPiZ4rT+OqrdrCzL6jKMjL8Dvc3DOWo55xq3 hmnD017y6Luq4YOX1a0LxVImEnPNfVbObywAHVHWigYF24SHGejUl1mq0GFU3eBc+i0+ 4HAum0r3RMd2/Fi5xdgLxArpvqpboktLvAFluVoI51M3brK5e76tosXbhRaX1+w4evYI U0Rw==
MIME-Version: 1.0
X-Received: by 10.52.18.235 with SMTP id z11mr8149416vdd.39.1363388516930; Fri, 15 Mar 2013 16:01:56 -0700 (PDT)
Received: by 10.220.234.194 with HTTP; Fri, 15 Mar 2013 16:01:56 -0700 (PDT)
In-Reply-To: <CAK3OfOh4+tb5GAuyg+Uvh3h5=VYz--95E8ZPXMT1F9Dh5NQB-A@mail.gmail.com>
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> <CAK3OfOh4+tb5GAuyg+Uvh3h5=VYz--95E8ZPXMT1F9Dh5NQB-A@mail.gmail.com>
Date: Sat, 16 Mar 2013 03:01:56 +0400
Message-ID: <CAOhHAXwVXjmgtc=pE+PdWL5cx3nQW9Av8u73pqaBcrEYRgjt0g@mail.gmail.com>
From: Mohamad Badra <mbadra@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary="bcaec502d8283e1df304d7fea0a7"
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:01:58 -0000

On Sat, Mar 16, 2013 at 2:46 AM, Nico Williams <nico@cryptonector.com>wrote:

> On Fri, Mar 15, 2013 at 5:41 PM, 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?
>
> To save a round trip?
>
>
That you want to sacrifice it to avoid traffic analysis :)

I don't see how a round trip is saved here: HTTP allows their clients to
advertise the major version they support in the first request the client
send to the server (e.g. HTTP request). The server replies with the lower
of that suggested by the client and the highest supported by the server.
This version negotiation is part of HTTP request/response exchange, so
where is the saved round trip?

Badra

v2.23.0 | Report a Bug | By Email