Hi, I do not hold as strong position as Olafur here, but I concur that the document needs much better rationale. There’s no rationale for adopting the new GOST algorithm at the moment and I would especially like to hear why GOST 2012 should be standardized and EC-KCDSA (Korean) and ECGDSA (German) should not.
I specifically think that we should only standardize algorithms recommended by cfrg such as RFC 7748 or RFC 8439 (just example, not applicable). I consider the previous GOST standardization for DNSSEC to be a fiasco. I would also ask the WG to require a implementation report before we send this to WGLC. The support for GOST family of algorithms varies between the various crypto libraries. I found it problematic for the DNS vendors that OpenSSL supports the algs only in form of OpenSSL engine, and that said engine had last release in 2018. The project activity looks fine, but issues like this[1] don’t exactly fill me with trust, but at least there’s an active maintainer for the project. As of the adoption - I am indifferent, the things I mentioned could be done with or without WG adopting the document, but I think that the document should not become a RFC (not even Informational) before the items I mentioned are cleared. 1. https://github.com/gost-engine/engine/issues/91 Ondrej -- Ondřej Surý ond...@isc.org > On 16 Jun 2020, at 04:42, Olafur Gudmundsson <o...@ogud.com> wrote: > > > Thom > As I have before stated in the past, adding new DNSSEC algorithm is bad for > interoperability, > I oppose the adoption of this document unless there are better reasons put > forward why this algorithm is better than > the 4 ECC algorithms that have been standardized so far. > Better in this case could be stronger, faster, better post-quantum resistance > etc > > Also I want to point out this last call did not specify track so my > opposition is against all tracks, at this point. > > Olafur > > > > >> On Jun 3, 2020, at 5:07 PM, Tim Wicinski <tjw.i...@gmail.com> wrote: >> >> >> All, >> >> As we stated in the meeting and in our chairs actions, we're going to run >> regular call for adoptions over next few months. >> We are looking for *explicit* support for adoption. >> >> >> This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis >> >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/ >> >> Please review this draft to see if you think it is suitable for adoption >> by DNSOP, and comments to the list, clearly stating your view. >> >> Please also indicate if you are willing to contribute text, review, etc. >> >> This call for adoption ends: 15 June 2020 >> >> Thanks, >> tim wicinski >> DNSOP co-chair >> >> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
