Re: [TLS] Server-side missing_extension MUSTs

Hubert Kario <> Thu, 14 July 2016 11:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB74A12D753 for <>; Thu, 14 Jul 2016 04:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.209
X-Spam-Status: No, score=-8.209 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.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tu6J2ALaFBZu for <>; Thu, 14 Jul 2016 04:37:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5ADDF12D549 for <>; Thu, 14 Jul 2016 04:37:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB83F4883F; Thu, 14 Jul 2016 11:37:10 +0000 (UTC)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id u6EBb9GL027849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jul 2016 07:37:10 -0400
From: Hubert Kario <>
Date: Thu, 14 Jul 2016 13:37:08 +0200
Message-ID: <>
User-Agent: KMail/4.14.10 (Linux/4.6.3-300.fc24.x86_64; KDE/4.14.20; x86_64; ; )
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart6578271.a0n0SpiqmN"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 ( []); Thu, 14 Jul 2016 11:37:10 +0000 (UTC)
Archived-At: <>
Subject: Re: [TLS] Server-side missing_extension MUSTs
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Jul 2016 11:37:13 -0000

On Thursday 14 July 2016 09:17:06 Martin Thomson wrote:
> On 14 July 2016 at 03:01, Eric Rescorla <> wrote:
> >
> > Obviously, you could add a check that said that if an EC cipher suite was
> > advertised, then you had to look for key shares even if you picked one, but
> > it's not a check you otherwise need.
> Though you would miss an EC cipher suite that you didn't know about.
> And as far as the client is concerned, any cipher suite that the
> server didn't pick is potentially one that it didn't know about.

yes, but it's also a ciphersuite no other client will negotiate with that server

and that's why we don't say that server should complain that an extension
it does know about was sent despite there are no EC ciphers from its point of

you, as server, act on what you know and understand, and you check it
fastidiously, everything else you MUST completely ignore

ie. if you know about supported_groups extension you MUST check that the length
of extension matches exactly the length of array (minus the 2 bytes for length),
and that length is an even number but you MUST ignore any identifiers you
don't know about if they appear in the array

so server should check if, and only if, there are EC ciphers it knows about* in
the client hello, then it should check for the presence of the extension
and abort if it is missing

 * either ones it can negotiate now, or in general, but that's unimportant
   (I'd say the latter solution would be "cleaner")
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purky┼łova 99/71, 612 45, Brno, Czech Republic