Re: [TLS] sect571r1

Hubert Kario <hkario@redhat.com> Mon, 20 July 2015 13:08 UTC

Return-Path: <hkario@redhat.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 B49841A8778 for <tls@ietfa.amsl.com>; Mon, 20 Jul 2015 06:08:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 sUZmGsUzmCwp for <tls@ietfa.amsl.com>; Mon, 20 Jul 2015 06:08:38 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EA651A8704 for <tls@ietf.org>; Mon, 20 Jul 2015 06:08:38 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 08CE6345A83; Mon, 20 Jul 2015 13:08:38 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-167.brq.redhat.com [10.34.0.167]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6KD8aYD012063 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2015 09:08:37 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Mon, 20 Jul 2015 15:08:29 +0200
Message-ID: <3057217.d0lbc7rhst@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.9 (Linux/4.0.6-200.fc21.x86_64; KDE/4.14.9; x86_64; ; )
In-Reply-To: <201507152242.55454.davemgarrett@gmail.com>
References: <CAHOTMVJ+Rbvojqsa35ysLy8M1YwWEc2Qm7LDppQj7YKdpr0cfA@mail.gmail.com> <20150716014248.5333071.47478.4400@certicom.com> <201507152242.55454.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2369558.bqGuUOlXTo"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/krb1P6qMCr_GfIXtb3X0T5SdYj0>
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: Mon, 20 Jul 2015 13:08:39 -0000

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