Re: [TLS] sect571r1

Viktor Dukhovni <> Thu, 16 July 2015 04:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 30E0A1B3012 for <>; Wed, 15 Jul 2015 21:07:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id il3re6z6_i2t for <>; Wed, 15 Jul 2015 21:07:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 320FF1B3010 for <>; Wed, 15 Jul 2015 21:07:28 -0700 (PDT)
Received: by (Postfix, from userid 1034) id 4AEDB284D2B; Thu, 16 Jul 2015 04:07:27 +0000 (UTC)
Date: Thu, 16 Jul 2015 04:07:27 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
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: Thu, 16 Jul 2015 04:07:32 -0000

On Wed, Jul 15, 2015 at 11:52:13PM -0400, Jeffrey Walton wrote:

> > An auditor who believes that we can rigourously quantify the security
> > of these curves precisely enough to say which is stronger or more
> > closely "matches" AES-256, should be laughed out of the room and fired.
> Maybe so, but it is what it is. The IETF is probably not going to be
> able to change it.

Well, the auditor can't ask for curves with TLS that the specification
deprecates.  So removing oddball choices will help users fend off
clueless checklist-wielding auditors.

A modest amount of diversity is fine, but I would posit that anything
beyond a (conservative, performant, backup) triple is counterproductive.
Between the anticipated CFRG curves and the NIST prime curves, I
think we already have a couple too many.

The way I see it:

	conservative = Goldilocks
	performant = 25519
	backup = P-256, P-384, P-521 (legacy triple)

All the above should ultimately be MTI, with each peer prioritizing
either "conservantive" or "performant", and legacy peers do the
same with "P-256" or "P-384" (with P-521 as backup for both camps).

If there are signs that all these are about to fail, and we still
somehow are left with some curves we're willing to trust, we can
change the mix then.