Re: [TLS] sect571r1

Sean Turner <turners@ieca.com> Thu, 06 August 2015 13:22 UTC

Return-Path: <turners@ieca.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810B41B2F3B for <tls@ietfa.amsl.com>; Thu, 6 Aug 2015 06:22:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level:
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVPoDBWQH-HY for <tls@ietfa.amsl.com>; Thu, 6 Aug 2015 06:22:12 -0700 (PDT)
Received: from gateway33.websitewelcome.com (gateway33.websitewelcome.com [192.185.146.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C9441B2F28 for <tls@ietf.org>; Thu, 6 Aug 2015 06:22:12 -0700 (PDT)
Received: by gateway33.websitewelcome.com (Postfix, from userid 500) id DECB7C5217DDA; Thu, 6 Aug 2015 08:22:11 -0500 (CDT)
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway33.websitewelcome.com (Postfix) with ESMTP id CE959C5217D77 for <tls@ietf.org>; Thu, 6 Aug 2015 08:22:11 -0500 (CDT)
Received: from [96.231.221.219] (port=53708 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from <turners@ieca.com>) id 1ZNL7b-0008a4-9b for tls@ietf.org; Thu, 06 Aug 2015 08:22:11 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Sean Turner <turners@ieca.com>
In-Reply-To: <3057217.d0lbc7rhst@pintsize.usersys.redhat.com>
Date: Thu, 6 Aug 2015 09:22:09 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <F3F9B184-5167-4B16-8C92-8748DC5591E7@ieca.com>
References: <CAHOTMVJ+Rbvojqsa35ysLy8M1YwWEc2Qm7LDppQj7YKdpr0cfA@mail.gmail.com> <20150716014248.5333071.47478.4400@certicom.com> <201507152242.55454.davemgarrett@gmail.com> <3057217.d0lbc7rhst@pintsize.usersys.redhat.com>
To: "<tls@ietf.org>" <tls@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator3286.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source-IP: 96.231.221.219
X-Exim-ID: 1ZNL7b-0008a4-9b
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([172.16.0.112]) [96.231.221.219]:53708
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 12
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/k-U0xub4X-Yj7B32hlFUKAZpH3Y>
Subject: Re: [TLS] 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, 06 Aug 2015 13:22:14 -0000

I looks like we’ve come to WG consensus that the sect571r1 curve should be removed from the TLS 1.3 & 4492bis drafts.

spt

On Jul 20, 2015, at 09:08, Hubert Kario <hkario@redhat.com> wrote:

> On Wednesday 15 July 2015 22:42:54 Dave Garrett wrote:
>> On Wednesday, July 15, 2015 09:42:51 pm Dan Brown wrote:
>>> What about sect571k1, a Koblitz curve, aka NIST curve K-571? (By the way
>>> it has no unexplained constants...). Has it been removed already, or does
>>> the question also refer K-571 too?
>> Already dropped. That's obviously not irreversible, but it's unambiguously
>> in the virtually unused camp. The initial goal was to drop all largely
>> unused curves.
>> 
>> This question is just about sect571r1, which is far closer to secp384r1 &
>> secp521r1 in terms of usage, though still notably less. If you want to
>> argue for going with sect571k1 and not sect571r1, I don't think the WG is
>> on-board with that. Even if we continued to allow it, I doubt much would
>> add support for it to be worthwhile.
> 
> This is likely just an artefact of use of OpenSSL curve order, if K-571 was 
> first, the servers would likely select it over B-571 more often
> 
>> The scan I linked to found one; literally a single server on the entire
>> Internet,
> 
> _not_ a single server in the Internet, a single server among Alexa top 1 
> million websites - the scan is checking only a set of popular _websites_, not 
> even all popular services that use TLS, let alone the whole Internet
> 
>> that actually supports sect571k1 for ECDHE. The stats also show
>> 1575 "support" it, so I'm not sure what's going on there specifically. (if
>> someone can explain this bit of those stats, please do)
> 
> The "Supported PFS" section describes what the server selects if the client 
> advertises default OpenSSL order of all defined curves. The "Prefer" lines, 
> means that the ciphersuite selected by server by default uses this key 
> exchange.
> 
> IOW, if server supports FFDHE 2048 and ECDHE P-256 and prefers ECDHE, then the 
> server will be counted in three lines:
> DH,2048bits
> ECDH,P-256,256bits
> Prefer ECDH,P-256,256bits
> 
> The "Supported ECC curves" section describes what curves the server will use 
> for ECDHE key exchange if its preferred one is not advertised by client (in 
> most cases that means what happens if the client doesn't advertise P-256 
> curve). Then that curve is removed and the process repeated until the server 
> picks a ciphersuite that doesn't use ECDHE or aborts connection.
> 
> feel free to ask more questions about the scans if something is still unclear
> -- 
> Regards,
> Hubert Kario
> Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic_______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls