[TLS] (selection criteria for crypto primitives) Re: sect571r1

Rene Struik <rstruik.ext@gmail.com> Thu, 16 July 2015 01:42 UTC

Return-Path: <rstruik.ext@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 138941B2CEF for <tls@ietfa.amsl.com>; Wed, 15 Jul 2015 18:42:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JgBUYwa28d4A for <tls@ietfa.amsl.com>; Wed, 15 Jul 2015 18:42:29 -0700 (PDT)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420381B2CD8 for <tls@ietf.org>; Wed, 15 Jul 2015 18:42:29 -0700 (PDT)
Received: by ieik3 with SMTP id k3so46631542iei.3 for <tls@ietf.org>; Wed, 15 Jul 2015 18:42:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=KzT26AuQTKtWDLpeTko4d9T7iNjhKKdsH56k3wKmrdI=; b=Awk0zakgAoXsbajMybIS0XVezsY59pESlUUV9wy0nBRhUmPY7EfqYEi1qzRCyrfrex ECNDr31XwLWhDkE+A99Y0RCeMmapZYJ0iXhCuqj4j29LYz2d+NMCgrJGHD+FdjF0uq08 DY53cIDVLiPrZ4xVlu/x7vnGNENJ3MkOlm8ExqUs7XConsqsVZAyWWmrmsGUQ/PPnWKi nTR5kE8nZUUik9QqbLMlp6Du6+qdcNAK4DO1VBi36+MqLHBCqvw8xwRWqDYqJARvAnB2 UyLx/mrEU8OeaD7RlMGKlGjVfavCRE2n10wzRUf4oTenx2zGlZHDvjXpDs/bXdMVYokA EVBA==
X-Received: by with SMTP id 33mr8587889iod.132.1437010948740; Wed, 15 Jul 2015 18:42:28 -0700 (PDT)
Received: from [] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. []) by smtp.gmail.com with ESMTPSA id ji7sm555598igb.2.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jul 2015 18:42:27 -0700 (PDT)
Message-ID: <55A70C01.8010907@gmail.com>
Date: Wed, 15 Jul 2015 21:42:25 -0400
From: Rene Struik <rstruik.ext@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: mrex@sap.com, Tony Arcieri <bascule@gmail.com>
References: <20150716002056.8BD691A1E9@ld9781.wdf.sap.corp>
In-Reply-To: <20150716002056.8BD691A1E9@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/0yW6TeOGD6Nex7APE-dskDTAA2Y>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: [TLS] (selection criteria for crypto primitives) Re: sect571r1
X-BeenThere: tls@ietf.org
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." <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, 16 Jul 2015 01:42:31 -0000

Dear colleagues:

It seems prudent to keep some diversity of the gene pool and not only 
have curves defined over prime curves. Similarly, one should perhaps 
have some diversity of gene pool criteria within the set of recommend 
curves and not only include special primes. Should some problem with a 
particular subclass show up over time, one then at least has other 
classes available.

On a general note, I do not understand what is wrong with having a 
dictionary of curves that is well-specified, but whose members are not 
all widely used. To my knowledge, having a dictionary does not force 
everyone to use every term in this (mandatory vs. optional to implement 
vs. mandatory to use, etc.).

If one follows the line of reasoning of some people on the mailing list 
earlier today, doesn't this also call into question Brainpool curves, 
or, e.g., the Misty cipher, etc.? Moreover, this certainly calls into 
question why one would have a whole set of new DLP groups (which 
certainly cannot be widely used yet, since the ink to write the 
parameters down is still wet). What about RSA-1024, etc.?

I would suggest one to have a clear criteria by which to judge 
inclusion/exclusion of cryptographic algorithms.

As a final note: if one can define curves explicitly, then removing 
these from a list does  not really remove them, except "pestering" 
people who would like to use them by forcing sending big chunks of 
descriptive text instead of short-hand references.

Best regards, Rene

On 7/15/2015 8:20 PM, Martin Rex wrote:
> Tony Arcieri wrote:
> [ Charset UTF-8 unsupported, converting... ]
>> Dave Garrett <davemgarrett@gmail.com> wrote:
>>> It's the most used of the rarely used curves.
>> I think all "rarely used curves" should be removed from TLS. Specifically,
>> I think it would make sense for TLS to adopt a curve portfolio like this:
>> - CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks
>> - NIST curves (SUPPORTED): P-256, P-384, P-521
> P-256 and P-384 seem to be pretty important to some folks
> (those with a NIST/NSA Suite B checklist).  I'm OK with P-521,
> but I would prefer to get rid of pretty much all _other_
> NIST curves with unexplained parameters, including 571
> Either the NIST curves with unexplained constants _are_ backdoored,
> then you get screwed no matter which one of them you use.
> Or the NIST curves are OK, then P-521 will be good enough.  IMO.
> -Martin
> Microsoft SChannel seems to implent the 3 NIST curves (P-256, P-384, P-521),
> and MSIE 10 exhibits a curious behaviour on my Win7 machine:
> when only TLSv1.0 is enabled, then MSIE 10 sends a ClientHello
> with P-521 as the first curve in the named_curve extension.
> when TLSv1.2 is also enabled, then MSIE 10 sends a ClientHello
> with P-256 as the first curve in the named_curve extension.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363