Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts

On Mon, Mar 18, 2019, 8:51 AM denis bider <denisbider.ietf@gmail.com> wrote:

> (removed CFRG from CC since not directly relevant)
>
> Exactly. Currently, the direction of SSH is dictated by OpenSSH, which is
> the de facto standard (in a loose alliance with other open source
> implementations like libssh and PuTTY).
>
> I'm not sure about the personal circumstances of each individual involved
> with these projects, but the requirements of IETF's "rigorous" processes
> are "rigorous"; and the motivation for volunteers to participate is
> approximately none. Yet these volunteers, as a group, determine the
> protocol's direction.
>
> As a standards organization, IETF is not competing with ISO (which
> requires anyone who wants to achieve something to travel to places like
> Hawaii), it is competing with GitHub. When OpenSSH wants to do something,
> they don't start a WG, they just publish stuff in their PROTOCOL file:
>
> https://github.com/openssh/openssh-portable/blob/master/PROTOCOL
>
> Currently:
>
> - The dominant encryption mechanism in SSH is not specified by IETF. It is
> "aes128-gcm@openssh.com" and "aes256-gcm@openssh.com", documented in that
> PROTOCOL file.
>
> - Encrypt-then-MAC in SSH is not specified by IETF. It is vaguely
> documented in that PROTOCOL file.
>
> - Host key synchronization (an extremely useful feature) is not specified
> by IETF - it's in that PROTOCOL file.
>
> This is just the tip of the iceberg. The PROTOCOL file contains a bunch of
> other things that are underspecified and under-standardized, but
> IMPLEMENTED, because no one wants to follow the IETF's "rigorous" process
> to charter a WG for every change.
>
> What makes this tragic is that it's unnecessary. SSH version 2 was
> standardized as an IETF WG. Then, because of the IETF rules, the WG
> disbanded.
>
> The IETF is literally handing off standardization to be done half-assedly
> at GitHub, and treating this as a success.
>

Forgive me for thinking this represents running code and rough consensus.
What is the benefit of turning  these enhancements into RFCs to the OpenSSH
project?

Also other streams then the IETF one exist. So what actually is the problem
that needs solving with SSH?

>
>
> On Mon, Mar 18, 2019 at 1:23 AM Peter Gutmann <pgut001@cs.auckland.ac.nz>
> wrote:
>
>> denis bider <denisbider..ietf@gmail.com <denisbider.ietf@gmail.com>>
>> writes:
>>
>> >SSH is full of underdocumented, partly functional custom extensions (to
>> >cryptography, compression, SFTP, port forwarding, host key
>> synchronization,
>> >VPN, and more), most of which could be better designed, better
>> documented and
>> >standardized
>>
>> +1.  Mind you given the hassle in setting up a WG for it and getting
>> things
>> through the IETF, it might be easier to just set up a Github repository
>> for
>> documentation on what does what and how and rely on Google to point
>> people to
>> it.
>>
>> Peter.
>>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>