Dear Ondřej, As we have different statuses for the algorithm, I don't think the CFRG adoption is required.
I don't think there are good or bad time periods to adopt nation-wide crypto profiles. For me, the difference between the GOST profile and hypothetical Korean or German profile is close to zero, and if anybody brings such a profile for standardization, I'd like to support it. As we have different statuses for the algorithms, I don't think the CFRG adoption is required. Speaking about the implementation, I'll have to put on the hat of the GOST engine maintainer. The open-source implementation of the GOST crypto is available in OpenSSL (as engine), LibreSSL (being the part of the core), and GnuTLS. The project activity of the gost-engine is limited by the coordination of the life circles between the Russian Standard body and OpenSSL. The issue you refer to is backdated almost two years ago, and I have some (rather vague, though) plans to make a new release as some improvements worth backporting appeared recently and some more are expected. On Tue, Jun 16, 2020 at 10:53 AM Ondřej Surý <ond...@isc.org> wrote: > 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 > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- SY, Dmitry Belyavsky
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
