Re: [TLS] MUST <x> or what?

Peter Gutmann <> Fri, 28 August 2015 04:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 960A31B31C6 for <>; Thu, 27 Aug 2015 21:29:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 18GLasabD6fF for <>; Thu, 27 Aug 2015 21:29:14 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B00A1B31BE for <>; Thu, 27 Aug 2015 21:29:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1440736154; x=1472272154; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lhaK7XFFdW3GhLJ547HQ6+DcMq44RTGlKK5+iFPDfxY=; b=ZdRiwIWiZrFswpS+HaHskOGDRtUw+pU81e+VVipj8a6LJeVoIjoNjcf+ vFwGf/x5zWcsM8El+6d4TNpoevdOCE4eS7YqwYB908sGRk1Fb7Nli2lNJ cXDNpAZR38QNLuQ0LdE1kJNLbqv5LHD687Jd0+VDE2/8AZqeI+H0/Ka1/ /vSVIleB0ugB331wCMywgr0WzUHJgK0zDKU7HkG0LkNnrtvzN7g72AwAA EeoXCRecn8DYNDPb25M44DDXy6TnwC0atNnrXbdtehpUtwrJrPYo28Y9S LpM0Nil3Rff58/pZnxaQHeJ1Tsy3ROygoBfpxcnE6bDgHucBEJ3+zNWf+ A==;
X-IronPort-AV: E=Sophos;i="5.17,424,1437393600"; d="scan'208";a="38272835"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 28 Aug 2015 16:29:13 +1200
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Fri, 28 Aug 2015 16:29:12 +1200
From: Peter Gutmann <>
To: Martin Thomson <>, EKR <>
Thread-Topic: [TLS] MUST <x> or what?
Thread-Index: AQHQ4Pj2LgOoeHtO7kayfT/An/ayC54fb5KAgAABvoCAAAoEAIABVqzI
Date: Fri, 28 Aug 2015 04:29:11 +0000
Message-ID: <>
References: <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] MUST <x> or what?
X-Mailman-Version: 2.1.15
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: Fri, 28 Aug 2015 04:29:15 -0000

Martin Thomson <>; writes:

>The opposite in fact. NSS checks extensions first. That is how we filter out 
>ECC cipher suites if the named_groups extension doesn't list anything we 

I have to do the same thing, bouncing back and forth between cipher suites and
extensions in order to find something that fits.  That was the motivation for
the creation of the "Standardised ECC Cipher Suites for TLS" draft:

   TLS-ECC [3] provides an extremely flexible, and by extension
   extremely complex means of specifying a large number of options
   involving the use of ECC algorithms for TLS [2].  As such the "cipher
   suites" in TLS-ECC [3] and by extension TLS-ECC-Brainpool [4] aren't
   suites in the conventional TLS sense but more an indication of intent
   to negotiate a Chinese menu, with details to be decided on later via
   various TLS extensions and parameter settings.  This makes deciding
   on a particular suite nondeterministic, since later parameter choices
   and settings can negate the initial "cipher suite" choice, requiring
   returning to the suite list to try with another Chinese-menu suite in
   the hope that later parameter choices allow it to be used.