Re: [TLS] Supported Versions extension

Ilari Liusvaara <ilariliusvaara@welho.com> Mon, 17 October 2016 20:37 UTC

Return-Path: <ilariliusvaara@welho.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 92277129998 for <tls@ietfa.amsl.com>; Mon, 17 Oct 2016 13:37:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level:
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
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 5CV1XgD1pMnm for <tls@ietfa.amsl.com>; Mon, 17 Oct 2016 13:37:50 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id A91AB12940F for <tls@ietf.org>; Mon, 17 Oct 2016 13:37:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 4B08D13EB4 for <tls@ietf.org>; Mon, 17 Oct 2016 23:37:49 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id 006_e3as1c3x for <tls@ietf.org>; Mon, 17 Oct 2016 23:37:49 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id E5E212315 for <tls@ietf.org>; Mon, 17 Oct 2016 23:37:48 +0300 (EEST)
Date: Mon, 17 Oct 2016 23:37:41 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: tls@ietf.org
Message-ID: <20161017203741.GA26847@LK-Perkele-V2.elisa-laajakaista.fi>
References: <1536297.j5uQUWNHeS@pintsize.usersys.redhat.com> <CAFewVt6_6PK09DjTQZnU5eKLVgJG7o8e7wDheANBQU4ms-Oe7w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAFewVt6_6PK09DjTQZnU5eKLVgJG7o8e7wDheANBQU4ms-Oe7w@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YA5CHu3mO7cg91gtZTgDjEMO6y0>
Subject: Re: [TLS] Supported Versions extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 17 Oct 2016 20:37:52 -0000

On Mon, Oct 17, 2016 at 10:25:07AM -1000, Brian Smith wrote:
> Hubert Kario <hkario@redhat.com> wrote:
> 
> > Currently the description of the extension states that only TLS versions
> > can
> > be listed in the extension and all unknown versions must be ignored.
> >
> > I wonder if making it explicit that {3, 0} and any lower values MUST NOT be
> > advertised wouldn't be a good idea, if only to hammer it that SSL3 must
> > not be
> > used.
> >
> 
> AFAICT, there's no need to list any version in that extension lower than
> TLS 1.2, and maybe not even TLS 1.2. If the server understand the extension
> then it is (almost?) definitely a TLS 1.3+ implementation, so it should
> choose TLS 1.3 or later. If the server doesn't understand the extension
> then it will use the ClientHello.legacy_version field for version
> negotiation.
> 
> Therefore, I suggest the following change:
> 
> OLD: "Implementations of this specification MUST send this extension
> containing all versions of TLS which they are prepared to negotiate. For
> this specification, that means minimally {3, 4}, but if previous versions
> of TLS are supported, they MUST be present as well."
> 
> NEW: "Implementations of this specification MUST send this extension
> containing all versions of TLS from TLS 1.3 onwards (only) which they are
> prepared to negotiate. For this specification, that means minimally {3, 4}.
> If previous versions of TLS are supported, they MUST NOT be present."

Omitting TLS 1.2 causes failures in some downnegotiation cases (when there
are higher versions supported, but not overlapping).

OTOH, negotiating 1.0 or 1.1 with this extension supported at both sides
is very unlikely.


-Ilari