Re: [TLS] sect571r1

[Sean Turner <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls