Re: [TLS] draft-ietf-tls-tls13-24 supported_versions complexity

Eric Rescorla <> Thu, 01 March 2018 13:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68BE51273B1 for <>; Thu, 1 Mar 2018 05:38:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GN3cPPdTZChX for <>; Thu, 1 Mar 2018 05:38:57 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 39A6A12785F for <>; Thu, 1 Mar 2018 05:38:56 -0800 (PST)
Received: by with SMTP id m13so7478187qtg.13 for <>; Thu, 01 Mar 2018 05:38:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T8H9ICbPybdphVZZTC4eeMjdsp68lc3kxADP5m5AZVI=; b=SiMDm55EOnL+At+jId0Wxeu5VViawPE6U9J8VhzMmWdh+VLIBLKgRltQqW4ilJ6CLD kcTtot46L8m2TKcqR23f7ujZ8+WyBySkG7dANMOL7bcT5eTtFaSehUvH6qI6TOpsD0Kx /h9RLeIzlrb+rfQTrIe3MpWKuLDPngLIdjP0PucSYJWXuNuWSt/6cy0HgSvN8XboJyAK ORT+jvqHvw1dLgAPqKR8FIIPi+6ASAASrrCc7LXSOIn4w+YtBL/N1zi1BqbNOk7dgbMe d/ilpJmVFzhrQWj46HMrpA0X19mxln9yCPn/qobmF6i7qDKRU1TviXb/gxJZ+sAQ5Zz6 lLCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T8H9ICbPybdphVZZTC4eeMjdsp68lc3kxADP5m5AZVI=; b=AelU42s/2FQhzmgNXtaG2/lsLdeUbKuqlVX/alyJVEoa/z/v4vOyzmRz61WF3OjHJN txm8C0we+Fe19f4GJ8nzaU6totVSTGye6bdFENBIRTiAKAeott5Xd34Ia1a/NZm4scQH qeth7j6TlfAntqputqD8pWhRqssgvXilPyKCD9e2oaXVzjeDXPWBTtBQknVbGi6gloXx u1JEF44WUblI6aFxterzFrm6xfohdeHKG3P5j9iNiRaqNMHA0yCcXAhJ/KDzoWaGHB11 47g4PPfmK9Q9WV/+W9+YKgH1fL8aC902h4ijgdOuD6KR9O9o37c6+/J8HHZR5E/gCXNX VzYQ==
X-Gm-Message-State: AElRT7Et4m1EXGXjHEtrQvkA3JGZZW/FX2hB4fJXrYFxHS3udXfstBrZ esAQXLDuh1GSGuRQrfGy3pNlJojVpbhxydxqN+DbXA==
X-Google-Smtp-Source: AG47ELtiN0c/TxWw+piZckyDsN1CTKqUA6SKaNTds+s7uPAhPdO71YX4mjHsZsOq10jKCOfXGpOdg9oKkeumwMbBfMU=
X-Received: by with SMTP id r11mr3017655qti.133.1519911535210; Thu, 01 Mar 2018 05:38:55 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 1 Mar 2018 05:38:14 -0800 (PST)
In-Reply-To: <>
References: <>
From: Eric Rescorla <>
Date: Thu, 01 Mar 2018 05:38:14 -0800
Message-ID: <>
To: Nikos Mavrogiannopoulos <>
Cc: IETF discussion list <>,, "<>" <>
Content-Type: multipart/alternative; boundary="089e08229d68258642056659fba8"
Archived-At: <>
Subject: Re: [TLS] draft-ietf-tls-tls13-24 supported_versions complexity
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Mar 2018 13:38:58 -0000

On Thu, Mar 1, 2018 at 5:24 AM, Nikos Mavrogiannopoulos <>

> The TLS draft after version -21 requires TLS1.3 servers to negotiate
> pre-TLS1.3 versions with a new, mechanism. The document states:
>    "If this extension is present, servers MUST ignore the
>    ClientHello.legacy_version value and MUST use only the
>    "supported_versions" extension to determine client preferences."
> ...
>    "Note that this mechanism makes it possible to negotiate a
>    version prior to TLS 1.2 if one side supports a sparse range."
> At this point, a server receiving a supported_versions extension which
> contains the single value 'TLS 1.0' has to follow the draft's
> recommendations and do:
>   1. It MUST set the ServerHello.legacy_version field to 0x0303
>      (TLS 1.2).
>   2. On the serverHello extensions include a supported_versions
>      extension and advertise TLS1.0
> That modifies the way TLS 1.1  or TLS 1.0 are negotiated, possibly
> introducing new issues with middle-boxes which see TLS1.2 in the
> ServerHello but TLS1.0 anywhere else. That is also a quite impossible
> code path (why would an implementation negotiate TLS1.0 using a TLS1.3
> mechanism?).

The text you quote explains how this can happen:
- A supports TLS 1.1 and TLS 1.3 draft X
- B supports TLS 1.1 and TLS 1.3 draft Y

> It is however anticipated to be used for that purpose as
> this draft mentions:
>    "Servers should be prepared to receive ClientHellos that include
>     this extension but do not include 0x0304 in the list of versions."

It's been a while, but I believe this text was actually put in to allow for
the case that clients support TLS 1.3 draft versions but not TLS 1.3 RFC.

My recommendation to address that would to either ignore that extension
> if pre-TLS1.2 is negotiated, or revert to -21 draft behavior for pre-
> TLS1.3 protocol negotiation. That is, the server MUST not send the
> supported_versions extension if a pre-TLS1.3 protocol is to be
> negotiated. The first case ensures that there is a single way to
> negotiate TLS1.x, where x<3, and the second that the clientHello
> extension is only used informatively.

I'm not in favor of either of these changes at this time. IMO it's more
straightforward to have an immediate branch on the presence of the
extension and then use only that.


> regards,
> Nikos