Re: [TLS] sect571r1

[Hubert Kario <[e-mail]>]

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