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.****
>



-- 
.- ... .... --- -.-