On 03/27/18 10:22, Paul Hoffman wrote: > On 27 Mar 2018, at 10:21, Michael Sinatra wrote: > >> My goal is to basically avoid confusion and just tell people to use the >> strongest algorithm they can reasonably use. I.e. follow the CNSA >> recommendations and don't spend a lot of time thinking about the >> application. > > The CNSA will likely be updated in the future to actually deal with the > issues, or be supplanted altogether with something from a different > agency that is better written. Telling people "just follow this > poorly-worded doc" is not what this WG should be doing.
Hi Paul: To be clear, I am not asking the WG to refer to the CNSA. I am merely asking the WG not to create something that can be construed as fundamentally inconsistent with it. I propose replacing: "ECDSAP384SHA384 share the same properties as ECDSAP256SHA256, but offers only a little advantage over ECDSAP256SHA256 and has not seen wide deployment, so the usage of this algorithm is discouraged, especially for signing." WITH: "ECDSAP384SHA384 share the same properties as ECDSAP256SHA256, but offers a modest security advantage over ECDSAP256SHA256 (192-bits of strength versus 128-bits). For most applications of DNSSEC, ECDSAP256SHA256 should be satisfactory and robust for the foreseeable future, and is therefore recommended for signing. While it is unlikely for a DNSSEC use case which requires 192-bit security strength to arise, ECDSA384SHA384 is provided for such applications and it MAY be used for signing in these cases." This also makes the discussion in this draft more consistent with RFC 6605's discussion of ECDSAP384SHA384 and RFC 8080's discussion of Ed448. michael _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
