Re: [saag] SSH & Ntruprime

Simon,

Thanks for your comments.

In terms of support for SSH in IETF, I believe that can be accomplished in
several ways based on this thread:

1. Publish SSH related specifications as RFCs
2. Support the review process from RFC9519 (We're working to resolve the
issue with the list, thanks for reporting it)

I don't think using IDs to document SSH algorithms and then never
publishing those drafts helps either community.

Regards,

OS

On Tue, Mar 26, 2024 at 7:49 AM Simon Josefsson <simon=
40josefsson.org@dmarc.ietf.org> wrote:

> Eric Rescorla <ekr@rtfm.com> writes:
>
> > Do you have any concrete examples of when an algorithm has been specified
> > by ID and then someone has been confused about how to implement it?
>
> I believe there are plenty of examples of that, with confusion
> interacting at different levels between implementation, deployment and
> early drafts.
>
> Blocking publication of specifications for a protocol pending some
> unspecified "future discussion" usually amount to eventually
> documentating the infected community history; creating something else
> that is incompatible; or giving up.  Some examples I recall myself:
>
> * Protected EAP -- see
>
> https://en.wikipedia.org/wiki/Protected_Extensible_Authentication_Protocol
>   for brief history that refers to some early draft specifications.
>   Clarifying parts of the protocol in the draft led to effectively
>   creating different protocol version, since implementers understood it
>   in different ways.  Publishing as RFC was blocked even though is
>   widely implemented and still in use.
>
> * Early TLS channel bindings - some of the confusion is discussed in
>   https://www.rfc-editor.org/rfc/rfc5929#section-1
>
> * OpenPGP -- the crypto-refresh draft had early implementations that
>   were deployed and the draft later changing, leading to having to bump
>   code point allocation leading to the v4 vs v5 vs v6 community
>   fracture.
>
> For SSH there has been repeated poor communication between the SSH
> implementer community and the IETF community, each side effectively
> accusing the other of acting on bad faith and going down their own road.
> I don't think this thread will improve that situation -- on the contrary
> -- but it gives an illustration that there are still valid reasons for
> this lack of co-operation, with people in the IETF acting to exclude
> contributions.  I believe the quality of future SSH improvements in the
> IETF is negatively affected as a result, with Internet users everywhere
> hurt as a consequence.
>
> /Simon
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>

-- 

ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>