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

[denis bider <[e-mail]>]

(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 "
[e-mail]" and "[e-mail]", 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.


On Mon, Mar 18, 2019 at 1:23 AM Peter Gutmann <[e-mail]>
wrote:

> denis bider <[e-mail]> 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.
>