Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis

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ý <ondrej@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ý
> ondrej@isc.org
>
> > On 16 Jun 2020, at 04:42, Olafur Gudmundsson <ogud@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.ietf@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