Didn’t we also agree to have Implementation Status in the drafts? There probably should be such section covering both crypto library support (OpenSSL is deprecating “engines” in favor of new “providers”).
This would be useful to both help the implementors decide whether it even
makes sense to implement the new algorithm and also understand even
whether the DNS server implementors are going to add support for GOST-2012
into their software.
Given the GOST-2001 fiasco, speaking with my ISC BIND 9 hat, I don’t feel
very motivated to do anything to add support for an algorithm that needs extra
OpenSSL engine to even work and then support the code for years while
the deployment is going to be again either national or none at all.
Adding new algorithms to DNSSEC should be driven by cryptographic needs,
and honestly how is this better than existing algorithms in DNSSEC?
I would expect the next DNSSEC algorithm is going to be quantum-resistant
which would bring benefit to the DNS and Internet, and not something produced
by a nation.
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
> On 15. 4. 2022, at 0:19, Michael StJohns <m...@nthpermutation.com> wrote:
>
> On 4/14/2022 5:09 PM, Paul Hoffman wrote:
>> On Feb 1, 2022, at 12:35 PM, Tim Wicinski <tjw.i...@gmail.com> wrote:
>>> We were reviewing the Working Group Last Call for this, and we received no
>>> comments. We know there was interest in at least moving this forward, but
>>> even Warren concurred we can't send this to the IESG unless there are folks
>>> saying they feel it is ready to be published.
>> That was a few months ago. There were only two responses, one negative, one
>> blandly positive ("seems reasonable").
>
> Hi Paul -
>
> Needs work is not a negative, it's a "not yet ready". I don't have a problem
> with the publication of such a document, and I agree with Russ that the
> changes between this and RFC5933 are reasonable - but RFC5933 isn't a model
> of clarity itself and shouldn't be used as justification to publish this
> document. So "needs work" not "ready for publication"
>
> Mike
>
>
>
>>
>> Can the chairs please say what they expect to do with this draft? I ask
>> because it is directly relevant to draft-ietf-dnsop-dnssec-bcp, where the
>> draft's predecessor is mentioned.
>>
>> --Paul Hoffman
>>
>> _______________________________________________
>> 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
