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 <hka...@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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
