Re: [TLS] "Draft Version" extension

Watson Ladd <watsonbladd@gmail.com> Mon, 11 August 2014 17:15 UTC

Return-Path: <watsonbladd@gmail.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 14D2E1A066C for <tls@ietfa.amsl.com>; Mon, 11 Aug 2014 10:15:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 XafNfHheH-8u for <tls@ietfa.amsl.com>; Mon, 11 Aug 2014 10:15:29 -0700 (PDT)
Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C6A1A0661 for <tls@ietf.org>; Mon, 11 Aug 2014 10:15:29 -0700 (PDT)
Received: by mail-yh0-f49.google.com with SMTP id b6so6498552yha.36 for <tls@ietf.org>; Mon, 11 Aug 2014 10:15:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qAyxxTfcIuUV9TPVKbFsB4eMQQI3ae3JZ2iRd/h0LGM=; b=fNelzgB0Leuhsiq0FHv4GZQ/a3JhBiFhA0WUGq21886BOwjnbkGmQ8hyk3Hw2WGmbf 54jTqcntz1mOcSj+ru+5Ktg9XbDYFM7kZkzcNMXIiPZSmnpp1jVnZMQQ2RNfEjqLVapV piZxq1wEaBawbeiEsqa9Ew8pJXr/MjeHIUJ9Oh8rTZUAJSVAfDRofRTJJ84PN3bb6y2q XkBf3P58TgW4Re2/2y0TI2Xh+Z1yPXyggwN0bl7m7hfgMuBERfR1v7wn66P2XqjSa7b4 gvEn4WFRT6RmoI2kU4KyuL+VmyDqzpzMEq7Qt0t5N4X0OjsQNoUE/xbt8TLTShXqe2iC UQVQ==
MIME-Version: 1.0
X-Received: by 10.236.134.208 with SMTP id s56mr45069876yhi.4.1407777328881; Mon, 11 Aug 2014 10:15:28 -0700 (PDT)
Received: by 10.170.202.8 with HTTP; Mon, 11 Aug 2014 10:15:28 -0700 (PDT)
Received: by 10.170.202.8 with HTTP; Mon, 11 Aug 2014 10:15:28 -0700 (PDT)
In-Reply-To: <CABcZeBN_Pi+6Bythe98VaVL09afZzdM8rB8weEZUkzmpk5nmmA@mail.gmail.com>
References: <CABcZeBN_Pi+6Bythe98VaVL09afZzdM8rB8weEZUkzmpk5nmmA@mail.gmail.com>
Date: Mon, 11 Aug 2014 10:15:28 -0700
Message-ID: <CACsn0ck7KKcRYJfCeXJkKD_bp=j5X3EPyw6MNKb94ywK8sYUsA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="20cf303a2bbb9c683705005db36b"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zdMB9Oe5M_-fjW2BkVwN0DqUaoc
Cc: tls@ietf.org
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: Mon, 11 Aug 2014 17:15:31 -0000

On Aug 11, 2014 9:55 AM, "Eric Rescorla" <ekr@rtfm.com> 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.

How would the server negotiate v2 vs v3? Nothing in the spec requires the
pain of a version jump. Other then that I think it is reasonable.

>
> 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.
>
> Thoughts?
> -Ekr
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>