Re: [TLS] ALPN - specifying client preference
Ashok Kumar <ashokkumar.j@gmail.com> Wed, 10 April 2013 05:20 UTC
Return-Path: <ashokkumar.j@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 7B23621F92F4 for <tls@ietfa.amsl.com>; Tue, 9 Apr 2013 22:20:39 -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 D04JIMWyhImV for <tls@ietfa.amsl.com>; Tue, 9 Apr 2013 22:20:38 -0700 (PDT)
Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8B621F92E9 for <tls@ietf.org>; Tue, 9 Apr 2013 22:20:38 -0700 (PDT)
Received: by mail-ve0-f180.google.com with SMTP id c13so70960vea.11 for <tls@ietf.org>; Tue, 09 Apr 2013 22:20:38 -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=vDYKoVK6SPk1oKitjZcEmCqv5ZrAgbQ5My4jJCefSKU=; b=dBzmYINrjJGj7tiqM/9ieIZG8Nh+AOEqep2XUkZKy7VjO2coNplnJ9Rxj3u5B4W+hM HrmNdFU/jdc2XH8T/h67N1CfLyGYR4I1T7TczP64bmom/ridwICf486fkrjEK1tW9jmb BIer+SNdhsJgvavkmc4ZWDl+UZyyZ+UsFuENrqag81sZqbt4RK7p+zjYmjKE0fAqCTpz ze9aNiA2IAYhHLi4fs73jXek8MzUWll9lPvDgEO2JdwdwEaHMEta1G3bFitJ6sL2EGkT 7UPVx6wGF3UrophiukSlElDh7jMykBjl0m40zrsVjAPL6IkJXhcUvj0zIt4VtIc62OqF mi3Q==
MIME-Version: 1.0
X-Received: by 10.220.95.10 with SMTP id b10mr416657vcn.10.1365571237977; Tue, 09 Apr 2013 22:20:37 -0700 (PDT)
Received: by 10.52.155.211 with HTTP; Tue, 9 Apr 2013 22:20:37 -0700 (PDT)
In-Reply-To: <e0de82710fd94b2d8f5a01e69146a171@BN1PR03MB072.namprd03.prod.outlook.com>
References: <CAOeYYRf4eJ0EHaWA-yfa+2GyvHQoqrXAY+e6aML6a1UCt9jhDg@mail.gmail.com> <e0de82710fd94b2d8f5a01e69146a171@BN1PR03MB072.namprd03.prod.outlook.com>
Date: Wed, 10 Apr 2013 10:50:37 +0530
Message-ID: <CAOeYYRd=6gKqOv5yx-YAbzOQA8f=vw17CS=QgDvAZpcYYWuicA@mail.gmail.com>
From: Ashok Kumar <ashokkumar.j@gmail.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Content-Type: multipart/alternative; boundary="001a11c1d8788e57ef04d9fad4b7"
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] ALPN - specifying client preference
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, 10 Apr 2013 05:20:39 -0000
Hi Andrei, I was thinking in terms of having options to prevent strict preference orders. Let's say in near future, browsers use ALPN to negotiate between HTTP/1.1, SPDY/3, HTTP/2.0 and client doesn't mind between SPDY/3, HTTP/2.0 but prefers either of those over HTTP/1.1. I was just thinking that the server need not pick one of the two just because it appears first and thinks the client prefers it. Now that I read your mail, "server SHOULD select protocol that the _server prefers_ among the protocols advertised by the client", I see that it's completely server's choice and hence such an feature may not be useful. Thanks, Ashok On Tue, Apr 9, 2013 at 10:36 PM, Andrei Popov <Andrei.Popov@microsoft.com>wrote: > Hi Ashok,**** > > ** ** > > In ALPN, the server SHOULD select the protocol that the server prefers > among the protocols advertised by the client. Having said that, the client > sends its list of supported protocols in descending order of preference > (most-preferred protocol first). This allows some freedom for the > server-side implementer to take the client’s preference into account, but > ultimately the protocol selection occurs on the server.**** > > ** ** > > In NPN, the client SHOULD select the first protocol advertised by the > server that it also supports, i.e. the server’s preferred protocol SHOULD > be selected by the client. An exception to this is the case where the > client does not support any of the server’s protocols, in which case the > client simply chooses the client’s most preferred protocol. So there is an > expectation that the client will honor the server’s preference, but > practically this depends on the client-side NPN implementation.**** > > ** ** > > As for the client preferring “all protocols equally”, can you elaborate on > the scenario? What would the server do differently if it had this > information?**** > > ** ** > > Thanks,**** > > ** ** > > Andrei**** > > ** ** > > *From:* tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] *On Behalf Of *Ashok > Kumar > *Sent:* Monday, April 8, 2013 11:42 PM > *To:* tls@ietf.org > *Subject:* [TLS] ALPN - specifying client preference**** > > ** ** > > With NPN, client could choose the protocol that it has better support for. > **** > > ** ** > > With ALPN, do we intend to add some mechanism where the client can specify > its preference? I believe the order in which the protocols are sent give > some preference, but is anyone interested in having options to say that > client prefers all protocols equally? **** > > ** ** > > Regards,**** > > Ashok**** > > ** ** > > P.S.: I'm new to TLS list and apologize if the query is not relevant. I > was thinking more in lines of HTTP headers having qvalues.**** > -- .- ... .... --- -.-
- [TLS] ALPN - specifying client preference Ashok Kumar
- Re: [TLS] ALPN - specifying client preference Andrei Popov
- Re: [TLS] ALPN - specifying client preference Ashok Kumar