Re: [TLS] supported_versions question

Hubert Kario <hkario@redhat.com> Tue, 15 November 2016 11:53 UTC

Return-Path: <hkario@redhat.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 730CB124281 for <tls@ietfa.amsl.com>; Tue, 15 Nov 2016 03:53:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.419
X-Spam-Level:
X-Spam-Status: No, score=-8.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 xBE8N8lH5jXv for <tls@ietfa.amsl.com>; Tue, 15 Nov 2016 03:53:18 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556311295A3 for <tls@ietf.org>; Tue, 15 Nov 2016 03:53:18 -0800 (PST)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CF02261BB4; Tue, 15 Nov 2016 11:53:17 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAFBrGrR021716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Nov 2016 06:53:17 -0500
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Tue, 15 Nov 2016 12:53:15 +0100
Message-ID: <3543263.QZeSEPR1jY@pintsize.usersys.redhat.com>
User-Agent: KMail/5.3.2 (Linux/4.8.6-201.fc24.x86_64; KDE/5.27.0; x86_64; ; )
In-Reply-To: <201610312019.15918.davemgarrett@gmail.com>
References: <CAMoSCWaVJy9f6NFy1Msc1_VSDxRFM2pruhecWb+22N4ct-t0+g@mail.gmail.com> <CAMoSCWbz8yhs5LMDfD1Hoc94s95a6JcRVmdeKnHeFWp9LdjFfA@mail.gmail.com> <201610312019.15918.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart4598304.q0ExPyyMog"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 15 Nov 2016 11:53:18 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/h3f6fLdQ821s1k37XKkgl9fA4o4>
Subject: Re: [TLS] supported_versions question
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: Tue, 15 Nov 2016 11:53:21 -0000

On Monday, 31 October 2016 20:19:15 CET Dave Garrett wrote:
> On Monday, October 31, 2016 08:05:59 pm Matt Caswell wrote:
> > On 31/10/16 23:53, Dave Garrett wrote:
> > >> I came up with some alternative wording that I think captures the
> > >> discussion:
> > >> 
> > >> https://github.com/tlswg/tls13-spec/pull/748
> > > 
> > > I see no reason to require servers to validate the legacy version value.
> > > That's just excess complexity. If the extension is there, then it
> > > should take absolute precedence. If not, use the old system. Nothing
> > > will have a higher value there except old probers.> 
> > If legacy_version == 0x0302 (TLS1.1), but highest supported_version is
> > 0x0303 (TLS1.2) - or vice versa, which client_version should be used
> > in an RSA key exchange calculation?
> 
> Why would this ever happen? What client is offering to support TLS 1.1 via
> the ClientHello field but offers only TLS 1.2 via the TLS 1.3 extension?
> This is a very contrived implementation error; if you need to account for
> it, abort the connection with an error. As to the vice versa, dropping
> 1.0/1.1 support from the extension avoids that.

could be a result of fallback dance

And I think it should be treated the same way signature_algorithms are - 
inapplicable to TLS1.1 and lower - thus ignore completely

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky┼łova 99/71, 612 45, Brno, Czech Republic