Re: [TLS] sect571r1

Dave Garrett <> Wed, 15 July 2015 21:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EB3E01B2CF6 for <>; Wed, 15 Jul 2015 14:39:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WQrkLtUSS2yH for <>; Wed, 15 Jul 2015 14:39:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E55BC1B2CF5 for <>; Wed, 15 Jul 2015 14:39:28 -0700 (PDT)
Received: by qkdl129 with SMTP id l129so38143301qkd.0 for <>; Wed, 15 Jul 2015 14:39:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=cYqRhhELv/JpBaY2JP0aOFSXj1AxAaZ/4p+OuWnThas=; b=tSqhWfgm2NqskC2dA7n+OTDOa3b0QwYO9dolyW/lOHctaEs58mI9/cTn6Bx6C2f1qz In3klQj3dlVifDGcG0PHBrps2GLcmf2Thu2iYg1pxx9rYwAbU+YTmi7bxbhz420yiJrC lQdjjWRlSPdCMT1UBNbguO0A/HYNzTKT7e4O8LRuaxwjno4fLaSbQcHJBJ1cGP5kApls /ERcYPwNfPkFjgDpXde0MqxJJ6o9v5dI9SldP6g52L5RoCyF6LCmuYBtH13+DX0wFaAg mW8LzQg2blLdJP/ssDTwY8gLTC9gtng+8HXDkQ1NndWkzOtwRLTi5+pr0ahMLLOwbwVK NOuw==
X-Received: by with SMTP id f91mr11649765qkh.51.1436996368195; Wed, 15 Jul 2015 14:39:28 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id w67sm2940048qgw.41.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 15 Jul 2015 14:39:27 -0700 (PDT)
From: Dave Garrett <>
To:, Tanja Lange <>
Date: Wed, 15 Jul 2015 17:39:26 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
Subject: Re: [TLS] sect571r1
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: Wed, 15 Jul 2015 21:39:31 -0000

On Wednesday, July 15, 2015 05:06:37 pm Tanja Lange wrote:
> > The main reason I think this warrants discussion is that dropping it would drop the maximum bits here, which whilst obviously not the only factor to take into account, will possibly not be desired by some. The main arguments for ditching is probably that it might not be safely implemented and nobody actually needs something this big.
> Removing it would drop the max number of bits but not necessarily the 
> max security. The exact security of binary curves is currently under
> discussion. The new algorithms offer at best an asymptotic speedup --
> but 571 might be big enough to fall under asymptotics.
> I understand that libraries support it, but is it actually being used?
> Does anybody have statistics on how many sites use it?

It's the most used of the rarely used curves.

Server-side support is generally low, however a number of servers prefer to use it for ECDHE. (usage is in the same order of magnitude as P-384 & P-521, though notably less) This is down from the previous month's results but up from the month before. Server support is at a similar rate to other rarely used larger curves, but still a fraction of a percent. Nothing requires it, outright.

It's important to note that the dropped range(s) of curves are listed as "MUST NOT" offer or negotiate for any TLS 1.3 implementation, though I haven't added any requirement to enforce that.

Dropping it really does drop down the max size drastically, but the general CFRG consensus seems to be that nothing above curve448 is even helpful and secp521r1 would still be permitted for those that want bigger numbers. (given the CFRG opinion, even secp521r1 should be on the chopping block, then)