Re: [TLS] "Draft Version" extension

Alexey Melnikov <alexey.melnikov@isode.com> Tue, 12 August 2014 18:26 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19AD01A06A0 for <tls@ietfa.amsl.com>; Tue, 12 Aug 2014 11:26:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.668
X-Spam-Level:
X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkNwl-kRwmEZ for <tls@ietfa.amsl.com>; Tue, 12 Aug 2014 11:26:26 -0700 (PDT)
Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 54ED31A04F1 for <tls@ietf.org>; Tue, 12 Aug 2014 11:26:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1407867985; d=isode.com; s=selector; i=@isode.com; bh=OWkYUGJVYsEBWuzPzcqdvNp3XwQvI2V3IXOC/+lYuGY=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=FLglFnJ7PUSgzEO6rrdRoOsfJ3ssMnxf0+gIBkZ6Q+83GIS1RnAmRFuprgngZOeysyEScn Dv5guScQ3eFATVK4bRfIMAtaS8ygjB1GNpNxi9BxXmAP+yptCXiywiezmpXQmC2JKvaSoi zs/DN5FBBD59Ai2TnM7T5Cn/vLIFQho=;
Received: from [172.20.1.47] ((unknown) [217.34.220.158]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id <U-pcUAAvQ2WO@waldorf.isode.com>; Tue, 12 Aug 2014 19:26:25 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <53EA5C50.70105@isode.com>
Date: Tue, 12 Aug 2014 19:26:24 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
To: Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
References: <CABcZeBN_Pi+6Bythe98VaVL09afZzdM8rB8weEZUkzmpk5nmmA@mail.gmail.com>
In-Reply-To: <CABcZeBN_Pi+6Bythe98VaVL09afZzdM8rB8weEZUkzmpk5nmmA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/up6nwCLH49j262ejGzpXMhjudgA
Subject: Re: [TLS] "Draft Version" extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 12 Aug 2014 18:26:28 -0000

On 11/08/2014 17:53, Eric Rescorla wrote:
> Experience with HTTP 2 has shown that it's convenient to be able to
> distinguish which draft version you're implementing so you don't end
> worrying about interop between various I-D versions. Accordingly,
> for TLS 1.3 I'd like to define a temporary extension that indicates which
> TLS 1.3 draft it implements. The idea here is that the client would signal
> TLS 1.3 and then "draft 3" and the server would only negotiate 1.3 if
> it had a compatible draft. Otherwise it would fall back to TLS 1.2.
>
> My proposed extension would be as follows:
>
> struct {
>   uint16 draft_version;
> } DraftVersionExtension;
>
> And would have a code point in the (unofficially) experimental range: 
> 0xff02.
> We would not need a permanent allocation since once TLS 1.3 ships you
> would  send no extension at all.
>
> I've implemented this in NSS and it's trivial to do.
Sounds like a good idea. I implemented similar extensions for other 
protocols.
>
> Thoughts?
> -Ekr