Re: [saag] SSH & Ntruprime

[Eric Rescorla <[e-mail]>]

On Sun, Mar 24, 2024 at 2:30 PM Mark D Baushke <[e-mail]> wrote:

> Hi Eric,
>
> There is apparently some reason that this information RFC should not be
> published as-is.
>
> It would make sense to incorporate that information into the terminal
> edition of the draft and update whatever flaws were found with the code
> point.
>
> Otherwise, what is the point of NOT publishing the Informational RFC draft?
>
> If the only reason to not publish the draft as an RFC was to avoid adding
> the IANA code point, then that section should be removed from the draft.
>

To the contrary, I think it would be fine to add a code point without
publishing an RFC.

I simply don't think there is much value in publishing RFCs to document
technologies that were not standardize by the IETF. People can just look at
the I-D. That's part of the purpose of relaxing the IANA requirements to
allow code point assignment without RFC publication.

-Ekr


> It seems untidy to leave it unpublished with no indication as to why.
>
> On Mar 24, 2024, at 11:17 AM, Eric Rescorla <[e-mail]> wrote:
>
>
>
> On Sun, Mar 24, 2024 at 8:27 AM Mark D Baushke <[e-mail]> wrote:
>
>> Hi Paul & Eric,
>>
>> The https://datatracker.ietf.org/doc/draft-josefsson-ntruprime-ssh/
>> draft is informational. The code point under discussion has been used
>> by five implementations of the Secure Shell (SSH) protocol, so that
>> seems to me to be a good time to document the protocol as an
>> informational RFC.
>>
>
> Why is an RFC necessary? The document is available at
> the link you indicate, and the IETF no longer deletes drafts.
>
> -Ekr
>
>
>
> If there is a technical or cryptographic reason that the described
>> protocol code point should not be used, then the draft should be
>> updated to include that information and the section asking IANA to
>> publish the code point be withdrawn before the document is published.
>>
>> All five of the SSH implementations could reasonably point to the
>> draft RFC to show that they are implementing the same code point with
>> the @openssh.com extension.
>>
>> Providing good information in the RFC about when to use or not to use
>> the code point would allow administrators of the client and server
>> software to better determine if they want to provide that algorithm to
>> their communities.
>>
>> I was not present when the draft was discussed and dropped. I have
>> looked and I do not see any reasons provided other than that it should
>> not be a Standards Track document. But it is NOT a standards track
>> document at present. Does that mean that removal of the IANA section
>> would be sufficient to allow it to be published showing the
>> implementation of the @openssh.com namespace?
>>
>> If there are good reasons that it should not be a standards track
>> cryptographic document, then it would be great if that would be
>> documented in the Security Considerations section.
>>
>> In fact, if there are good reasons why this code point should NOT be
>> used more generally, documenting it would be helpful to many.
>>
>> Everyone knows that cryptographic functionality is always moving
>> forward and that some stuff is not as secure as originally thought.
>> The RFCs should be there to help guide everyone on the best in class
>> and worst in class and give reasons.
>>
>> We do have RFCs that deprecate various algorithms that are deployed
>> widely. Is that what should happen with this draft? Should it document
>> the implementation and then say that it is not secure going forward?
>> Or, that other cryptographic primitives should be used that are faster
>> or less fragile? That is not for me to choose.
>>
>>
>> On Mar 22, 2024, at 2:56 PM, Paul Wouters <
>> paul.wouters=[e-mail]> wrote:
>>
>>
>>
>> On Mar 22, 2024, at 23:52, Eric Rescorla <[e-mail]> wrote:
>>
>> 
>> It already is documented, at the link listed above.
>>
>> The question is whether it needs to be an IETF RFC. As noted by Paul,
>> that is not necessary for it to be used in the field.
>>
>>
>> indeed. specifically, the ssh protocol has namespaces and only the space
>> without an @ symbol is within the IETF space. allocation in the @
>> openssh.com namespace shouldn't need to be copied into IETF RFCs or
>> registries. openssh should document its own namespace registry.
>>
>> the [e-mail] address shouldn't bounce and we are looking
>> into that issue.
>>
>> Paul
>>
>>
>>
>>
>>
>>
>>
>> -Ekr
>>
>>
>> On Fri, Mar 22, 2024 at 6:41 AM Harry Halpin <[e-mail]> wrote:
>>
>>>
>>>
>>> On Fri 22 Mar 2024 at 12:32, Loganaden Velvindron <[e-mail]>
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I went through SAAG minutes, and I noticed that the crypto panel
>>>> decided that this should not be standardized.
>>>>
>>>> https://datatracker.ietf.org/doc/draft-josefsson-ntruprime-ssh/
>>>>
>>>> OpenSSH publicly stated that they will keep offering
>>>> curve25519+sntrup761 even after ml-kem is standardized.
>>>>
>>>> Several SSH implementations also support this. Is it a good idea that
>>>> de-facto widespread adoption is not at least documented in a RFC ?
>>>
>>>
>>>
>>> Note that a number of other apps like Simplex Chat are also supporting
>>> NTRU prime. While not a standard per se, I also agree documenting it would
>>> be a good idea as some people will, for better or worse, not want to use
>>> ML-KEM.
>>>
>>>
>>>>
>>>> Saag youtube video:
>>>> https://youtu.be/pTUvyVxPGYw?t=1474
>>>>
>>>> _______________________________________________
>>>> saag mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/saag
>>>>
>>> _______________________________________________
>>> saag mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/saag
>>>
>> _______________________________________________
>> saag mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/saag
>>
>> _______________________________________________
>> saag mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/saag
>>
>>
>> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag
>
>
>