Re: [auth48] AUTH48: RFC-to-be 9558 <draft-makarenko-gost2012-dnssec-05> for your review

["Independent Submissions Editor (Eliot Lear)" <[e-mail]>]

Yes.  Thanks.  I needed to wait for some IETF smoke to clear. Approved.

On 02.04.2024 20:29, Alice Russo wrote:
> Hi Eliot,
> Checking in -- I believe we're awaiting your approval of this document for publication as an RFC:
>   https://www.rfc-editor.org/authors/rfc9558.html
>   https://www.rfc-editor.org/authors/rfc9558.txt
>   https://www.rfc-editor.org/authors/rfc9558.pdf
>
> My apologies if I've missed a mail since the one below.
>
> RFC Editor/ar
>
>> On Mar 18, 2024, at 12:18 AM, Independent Submissions Editor (Eliot Lear) <[e-mail]> wrote:
>>
>> Thanks, Alice.  Please expect no further action from me until after Friday.
>>
>> Eliot
>>
>> On 18.03.2024 07:49, Alice Russo wrote:
>>> Boris, Eliot,
>>>
>>> We have updated Section 8 accordingly. The updated files are here (please refresh):
>>>   https://www.rfc-editor.org/authors/rfc9558.html
>>>   https://www.rfc-editor.org/authors/rfc9558.txt
>>>   https://www.rfc-editor.org/authors/rfc9558.pdf
>>>   https://www.rfc-editor.org/authors/rfc9558.xml
>>>
>>> This diff file shows all changes from the approved I-D:
>>>   https://www.rfc-editor.org/authors/rfc9558-diff.html
>>>   https://www.rfc-editor.org/authors/rfc9558-rfcdiff.html (side by side)
>>>
>>> This diff file shows the changes made during AUTH48 thus far:
>>>   https://www.rfc-editor.org/authors/rfc9558-auth48diff.html
>>>
>>> This diff file shows only the most recent change:
>>>   https://www.rfc-editor.org/authors/rfc9558-lastrfcdiff.html
>>>
>>> We'd like to hear from both of you, to confirm the updates are as intended. This page shows the AUTH48 status of your document:
>>>   https://www.rfc-editor.org/auth48/rfc9558
>>>
>>> Thank you.
>>> RFC Editor/ar
>>>
>>>> On Mar 16, 2024, at 3:42 AM, bmakarenko=[e-mail] wrote:
>>>>
>>>> Eliot,
>>>>
>>>> We can change Security considerations section as it actually contradicts with the Section 1 which already says:
>>>>
>>>> GOST R 34.10-2012 and GOST R 34.11-2012 are Russian national standards.  Their cryptographic properties haven't been independently verified.
>>>>
>>>> We do not insist that GOST is unbreakable.
>>>>
>>>> I agree. "to be used" is better than "required" and will not confuse anyone outside Russia who (for unknown reason) would use GOST in DNSSEC.
>>>>
>>>> Boris
>>>> 15 мар. 2024 г. 17:11:18 Independent Submissions Editor (Eliot Lear) <[e-mail]>:
>>>>
>>>> Ok.  I've spotted some issues with Security Considerations.  First, RFC 7583 should be referenced.  Second, I don't know what this means:
>>>>
>>>>> unless GOST-only cryptography is required
>>>> Let's change "required" to "to be used".
>>>>
>>>> Lastly, discussing crypto strength here is not appropriate.  The only risk of this document is that GOST would be broken.  The only remedy is to change algorithms.   Again, RFC 7583 is applicable.
>>>>
>>>> So what does this mean to the text?
>>>>
>>>> These two paragraphs:
>>>>
>>>>> Currently, the cryptographic resistance of the GOST R 34.10-2012 digital signature algorithm is estimated as 2128 operations of multiple elliptic curve point computations on a prime modulus of order 2256.
>>>>> Currently, the cryptographic collision resistance of the GOST R 34.11-2012 hash algorithm is estimated as 2128 operations of computations of a step hash function.
>>>> Can come out.
>>>>
>>>> And then just add a sentence that says something like this:
>>>>
>>>>
>>>>> Like all algorithms, it is possible that a signficant flaw could be discovered with GOST R 34.11-2012.  In that case, deployments should rollover to another algorithm.  See RFC 7583 on the timing of such changes.
>>>> A caution about that required word in the text: if anyone thinks that it would be a good idea to legislate an algorithm, they'll create quite a mess when (not if) GOST (or any algorithm) is broken
>>>>
>>>> Eliot
>>>>
>>>>
>>>>
>>>> On 15.03.2024 04:19, Alice Russo wrote:
>>>>> Authors,
>>>>>
>>>>> Thank you for your reply. Based on your reply to #6, we have updated
>>>>> RFC 5208 [RFC5208], Section 5.
>>>>> to
>>>>> RFC 5958 [RFC5958], Section 2.
>>>>>
>>>>> The updated files are here (please refresh):
>>>>>    
>>>>> https://www.rfc-editor.org/authors/rfc9558.html
>>>>>
>>>>>    
>>>>> https://www.rfc-editor.org/authors/rfc9558.txt
>>>>>
>>>>>    
>>>>> https://www.rfc-editor.org/authors/rfc9558.pdf
>>>>>
>>>>>    
>>>>> https://www.rfc-editor.org/authors/rfc9558.xml
>>>>>
>>>>>
>>>>> This diff file shows all changes from the approved I-D:
>>>>>    
>>>>> https://www.rfc-editor.org/authors/rfc9558-diff.html
>>>>>
>>>>>    
>>>>> https://www.rfc-editor.org/authors/rfc9558-rfcdiff.html
>>>>>   (side by side)
>>>>>
>>>>> This diff file shows the changes made during AUTH48 thus far:
>>>>>    
>>>>> https://www.rfc-editor.org/authors/rfc9558-auth48diff.html
>>>>>
>>>>>
>>>>> This diff file shows only the most recent change:
>>>>>    
>>>>> https://www.rfc-editor.org/authors/rfc9558-lastrfcdiff.html
>>>>>
>>>>>
>>>>>
>>>>> 8 March, Boris wrote:
>>>>>
>>>>>> So, I approve the publication of the RFC.
>>>>>>
>>>>> 7 March, Vasily wrote the following, and answered the follow-up question on 12 March:
>>>>>
>>>>>> I agree with all modifications proposed by RFC Editors.
>>>>>>
>>>>> So, we have recorded your approvals; we await word from Eliot as the ISE. This page shows the AUTH48 status of your document:
>>>>>    
>>>>> https://www.rfc-editor.org/auth48/rfc9558
>>>>>
>>>>>
>>>>> Thank you.
>>>>> RFC Editor/ar
>>>>>
>>>>>
>>>>>> On Mar 12, 2024, at 12:46 AM, Василий Долматов <[e-mail]>
>>>>>>   wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 9 марта 2024 г., в 03:52, Василий Долматов <[e-mail]>
>>>>>>>   написал(а):
>>>>>>>
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> 9 марта 2024 г., в 00:00, Alice Russo <[e-mail]>
>>>>>>>>   написал(а):
>>>>>>>>
>>>>>>>> Authors, Eliot,
>>>>>>>>
>>>>>>>> Thank you for your replies; please see one follow-up below. The revised files are here (please refresh):
>>>>>>>>
>>>>>>>> https://www.rfc-editor.org/authors/rfc9558.html
>>>>>>>> https://www.rfc-editor.org/authors/rfc9558.txt
>>>>>>>> https://www.rfc-editor.org/authors/rfc9558.pdf
>>>>>>>> https://www.rfc-editor.org/authors/rfc9558.xml
>>>>>>>>
>>>>>>>>
>>>>>>>> This diff file shows all changes from the approved I-D:
>>>>>>>>
>>>>>>>> https://www.rfc-editor.org/authors/rfc9558-diff.html
>>>>>>>> https://www.rfc-editor.org/authors/rfc9558-rfcdiff.html
>>>>>>>>   (side by side)
>>>>>>>>
>>>>>>>> This diff file shows the changes made during AUTH48 thus far:
>>>>>>>>
>>>>>>>> https://www.rfc-editor.org/authors/rfc9558-auth48diff.html
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Please reply to #6. We have updated the text to RFC 5958; please provide the section number if you want to include that.  Also, does the sentence need any updates for accuracy?
>>>>>>>>
>>>>>> Also, there is no need to update text of the draft.
>>>>>>
>>>>>> «PrivateKeyInfo» is still used in RFC5958 and did not change its meaning.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> PrivateKeyInfo ::= OneAsymmetricKey
>>>>>>
>>>>>>       -- PrivateKeyInfo is used by [
>>>>>> P12
>>>>>> ].  If any items tagged as version
>>>>>>       -- 2 are used, the version must be v2, else the version should be
>>>>>>       -- v1.  When v1, PrivateKeyInfo is the same as it was in [
>>>>>> RFC5208].
>>>>>>
>>>>>>
>>>>>>>> RFC 5958 states:
>>>>>>>>    Changed the name "PrivateKeyInfo" to "OneAsymmetricKey".
>>>>>>>>
>>>>>>>>
>>>>>>>>> …
>>>>>>> Please use "Section 2» when referencing RFC5958,
>>>>>>>
>>>>>>>
>>>>>>> HTH,
>>>>>>>
>>>>>>> dol@
>>>>>>>
>>>>>>>
>>>>>>>> We will wait to hear from you again before continuing the publication
>>>>>>>> process. This page shows the AUTH48 status of your document:
>>>>>>>>
>>>>>>>> https://www.rfc-editor.org/auth48/rfc9558
>>>>>>>>
>>>>>>>>
>>>>>>>> Thank you.
>>>>>>>> RFC Editor/ar
>>>>>>>>
>>>>>>>> On Mar 7, 2024, at 2:26 PM,
>>>>>>>> [e-mail]
>>>>>>>>   wrote:
>>>>>>>>
>>>>>>>>> …
>>>>>>>>> …