Re: [TLS] Version negotiation, take two

Hubert Kario <hkario@redhat.com> Thu, 15 September 2016 10:22 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 8A4DB12B21B for <tls@ietfa.amsl.com>; Thu, 15 Sep 2016 03:22:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.43
X-Spam-Level:
X-Spam-Status: No, score=-8.43 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.508, 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 aE9rxHVS55Mn for <tls@ietfa.amsl.com>; Thu, 15 Sep 2016 03:22:05 -0700 (PDT)
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 D922612B138 for <tls@ietf.org>; Thu, 15 Sep 2016 03:22:05 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (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 72A43C056793; Thu, 15 Sep 2016 10:22:05 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8FAM3wr014602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2016 06:22:05 -0400
From: Hubert Kario <hkario@redhat.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Date: Thu, 15 Sep 2016 12:22:03 +0200
Message-ID: <1980227.k0brhKhleM@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.7.2-201.fc24.x86_64; KDE/5.26.0; x86_64; ; )
In-Reply-To: <CY1PR0301MB08422C3C4B9B4029C0B423B58CF10@CY1PR0301MB0842.namprd03.prod.outlook.com>
References: <CAF8qwaA86yytg29QOD_N7ARimh9QcNGU_nnr_OrxqCrvrk2MBg@mail.gmail.com> <2260393.jBGLD1rnRy@pintsize.usersys.redhat.com> <CY1PR0301MB08422C3C4B9B4029C0B423B58CF10@CY1PR0301MB0842.namprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart10685130.sgUTlz87Nv"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 15 Sep 2016 10:22:05 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fze_mUQcvpBdmnTdQYaCupxwy6o>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Version negotiation, take two
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: Thu, 15 Sep 2016 10:22:08 -0000

On Wednesday, 14 September 2016 19:02:14 CEST Andrei Popov wrote:
> > I don't think we should depart from the "highest mutually supported
> > version" negotiation algorithm...
> Correct, but it's not clear what represents "the highest" protocol version
> in the world where national TLS "standards" exist. Is country X-TLS (e.g.
> with integrated MITM support) a higher version than TLS 1.3? 

it means the same when I disable support for TLS 1.2 in current version of 
OpenSSL - it should negotiate TLS 1.1 as it is the highest mutually supported 
version. We don't care what the server's or client's code can do in absolute, 
we care what it is configured to do. See also: FALLBACK_SCSV handling.

> The server
> will make a choice based on the server's preferences. In a way, the
> proposed version negotiation mechanism makes it slightly easier to
> implement servers that support country X-TLS alongside IETF TLS versions.

and a list with opaque version identifiers (just int16 values) won't?
 
> Cheers,
> 
> Andrei
> 
> -----Original Message-----
> From: Hubert Kario [mailto:hkario@redhat.com] 
> Sent: Wednesday, September 14, 2016 11:03 AM
> To: Andrei Popov <Andrei.Popov@microsoft.com>;
> Cc: David Benjamin <davidben@chromium.org>;; tls@ietf.org
> Subject: Re: [TLS] Version negotiation, take two
> 
> On Wednesday, 14 September 2016 17:39:59 CEST Andrei Popov wrote:
> 
> > Do you mean a TLS extension code point per TLS version?
> 
> 
> yes, e.g. if extension 0x00a0 is present assume TLSv1.3 support, 0x0121,
> TLSv1.4; same way EMS and MtE works
 
> 
> > One argument against this was that this makes it difficult to express 
> > the client's prioritization of TLS versions, but IMHO arguably the 
> > server should not care.
> 
> 
> I don't think we should depart from the "highest mutually supported version"
> 
 negotiation algorithm, any kind of preference in the client list is
> likely to cause additional problems - version misnegotiation 
> if client will want to advertise support for TLSv1.3 and TLSv1.5 but not
> TLSv1.4 it will still be able to do that
>  
> 
> > -----Original Message-----
> > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Hubert Kario
> > Sent: Wednesday, September 14, 2016 9:40 AM
> > To: David Benjamin <davidben@chromium.org>;
> > Cc: tls@ietf.org
> > Subject: Re: [TLS] Version negotiation, take two
> > 
> > On Wednesday, 14 September 2016 16:17:50 CEST David Benjamin wrote:
> > 
> > 
> > > Yes, we find list intolerance too---servers which only look at the 
> > > second byte in a cipher suite, servers which forgot a default in 
> > > their NamedGroup switch-case, servers which get confused on unknown 
> > > HashAlgorithms, servers which require the final extension 
> > > non-empty---but this is dramatically less than version intolerance.
> > > It's usually within tolerable levels that we needn't resort to
> > > fallbacks.
> > > 
> > > The proposal switches from something which we know does not work to 
> > > something new. Perhaps this new one will break too, but it is very 
> > > similar to things that have worked before, and I am hopeful that 
> > > GREASE will help.
> > 
> > 
> > Was the option to do "one extension point = specific TLS version
> > supported"
 
> > discussed too? What arguments are there against it?
> > 
> > --
> > 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
> 
> 
> 
> --
> 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


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