[TLS] "Draft Version" extension

Eric Rescorla <ekr@rtfm.com> Mon, 11 August 2014 16:54 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id BC5101A066C for <tls@ietfa.amsl.com>; Mon, 11 Aug 2014 09:54:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id BEI75C8bhpTn for <tls@ietfa.amsl.com>; Mon, 11 Aug 2014 09:54:23 -0700 (PDT)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA9491A06D6 for <tls@ietf.org>; Mon, 11 Aug 2014 09:54:22 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id d1so4585525wiv.13 for <tls@ietf.org>; Mon, 11 Aug 2014 09:54:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=o2lS+/XjX2PiLxbUErxfoeKZsSoFwQ9bzyPO6ksUfl0=; b=dfj7j0AqgnZpd/2lAxcF+eLuR7k93nMUIAtybqA5+vyZk5anT0MNX9v/OwsBwqrvZ3 mursChQr4XLhp7es00L2Mr1Q52FygxtU/hnnU+zrlpuFf6Dc3l2JWHwAQEYPu3uRU0mi V5fBhwjYJKF4gsTfm5GDsgrVn+sf725thnN0H+gu3SQkvuxYwJTGkNZMJ9jfRk/4idKm ExLJ+ZCqoPQFTFR1+bbPZRSiCk2WCNnlbVuiU+OMstSZ13M4iKfGXDT8pHSjQm/NZngg k6oiz5ZZIFvqcj+KWGJbPKr5o8m4/CHReQH88VyEwfp6dJFjyJSY7sf4TNCOli59FlVV qENg==
X-Gm-Message-State: ALoCoQlfREHvP+UsjrnrpPstVrmL7f/ek2wUvilnH0F9e4OM3S4JjX4oDYVZQZkYQmFLjelJeWSw
X-Received: by with SMTP id ch4mr56087160wjb.59.1407776061539; Mon, 11 Aug 2014 09:54:21 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 11 Aug 2014 09:53:41 -0700 (PDT)
X-Originating-IP: [2620:101:80fc:232:6049:62d9:3779:ea46]
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 11 Aug 2014 09:53:41 -0700
Message-ID: <CABcZeBN_Pi+6Bythe98VaVL09afZzdM8rB8weEZUkzmpk5nmmA@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="047d7bd91d9e125f5205005d684f"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mMNj7XmuH680_vaHD9gIGZZ1zNY
Subject: [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 16:54:24 -0000

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