Hi Michael, > On 27 Mar 2018, at 02:30, Michael Sinatra <mich...@brokendns.net> wrote: > > > > On 03/22/18 08:08, Ondřej Surý wrote: > >> * Separate operational recommendations for default algorithm to >> ECDSAP256SHA256 >> * Deprecation of ECC-GOST (that actually happened elsewhere, so we reflect >> it here) >> >> I also squeezed paragraph about DS algorithm upgrade to operational >> considerations based on Roy Arends’ presentation. > > Regarding the comments (and general tone of the document) regarding > SHA384 and ECDSAP384SHA384: > > I am a bit uncomfortable with the document's disrecommendation of SHA384 > and ECDSAP384SHA384. The main reason for this is that for crypto > recommendations here in the USG, I often point people to the successor > of the NSA Suite B recommendations, now called the "Commercial National > Security Algorithm Suite" or CNSA. The recommendations here call for > SHA384 and P-384: > > https://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.cfm > > This document made a bit of a splash by pointing out that ECC is not > really quantum-resistant, which led to lots of "theories" as to why > NSA-IAD was making that claim. But the main utility of the document is > the crypto strength recommendations in the document. > > I am *very* sympathetic to the argument that P-256 and SHA-256 are "good > enough" for DNSSEC, especially since we can expect any such signatures > to have expired by the time 112-bit security is completely obsolete. My > motivation is around encouraging people to use the strongest security > available to them without having to worry about whether some > applications could get away with weaker security or not. > > Given that ECDSAP384SHA384 signatures and key lengths are still > significantly smaller than RSASHA256, the adage of "use the strongest > *practical* security algorithm that's available" would still seem to > point to ECDSAP384SHA384. For this reason, I am not comfortable with > the statement: > > "ECDSAP384SHA384 share the same properties as ECDSAP256SHA256, but > offers only a little advantage over ECDSAP256SHA256 and has not seen
Perhaps, we could say: “offers only a little advantage for DNSSEC over …” as that would be more accurate. We are (should be) aiming for most practical secure algorithm and that’s ECDSAP256SHA256 at the moment, and ED25519 in a foreseeable future (when there’s enough deployed base). It’s always search for a balance, and given there’s already huge deployed base for ECDSAP256SHA256, I think that discouraging users to use P384 is a reasonable thing to do. > wide deployment, so the usage of this algorithm is discouraged, > especially for signing.” …but the document authors are open to other suggestions, it’s a WG document, so we will follow WG advice. > I would also advocate changing the Signing > Recommendation to "MAY.” That would be fine with me (also to align with ED448 that share many of the properties of P384). I also expect that no implementation would actually rip-out P384 implementation they already have, and for new implementations the recommendation of SHOULD NOT and MAY is of similar value. Cheers, Ondrej -- Ondřej Surý ond...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
