Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT)

I think Mark has a more educated position on this than I do, but I can
respond to the following with a bit of practical information:

> Next, what's the explicit compatibility concern?  If your just waiting on
a key rollover
> or something along those lines, it's fine for this RFC to draw a hard
line.

One of the explicit compatibility concerns goes like this. More or less
directly taken from a real example:

- Organization X has a bunch of appliances (routers, etc) of model C.
- The appliances need to back up their log files.
- The appliances offer like two choices for backup, either plaintext FTP or
some old version of SSH+SFTP with only 1024-bit crypto, or only SHA-1, or
like that.
- The manufacturer no longer maintains the appliances. There are no updates
planned for SSH+SFTP on this hardware.
- Organization X wants to upgrade their SSH+SFTP server S on which they
receive the log files from the appliances.

Now the issue arises that a new RFC is out that says "MUST NOT support
1024-bit crypto" or "MUST NOT support SHA-1".

If it said "SHOULD NOT", then that's fine. Server S can come with 1024-bit
crypto and SHA-1 disabled by default, but users can enable if they want
compatibility with these old appliances.

But the spec says "MUST NOT". So now Server S, if it wants to be compliant,
cannot include 1024-bit crypto or SHA-1 at all. So now organization X
cannot update to a new version of server S because then they won't be able
to receive transfers from appliances that only support 1024-bit crypto or
SHA-1 or whatnot.

The organization is not throwing away the appliances also, because they
serve their purpose and are a big hardware investment. So as a result,
causal process goes like this:

idealist standards organization says "MUST NOT" support old stuff
=> new version of software cuts out support for old stuff
=> new version can't interoperate with old hardware
=> users don't upgrade to new version

Or alternately:

idealist standards organization says "MUST NOT" support old stuff
=> new version of software violates spec and supports it anyway
=> spec is toothless

Or alternately:

=> new version of software violates spec and supports "MUST NOT" algorithms
anyway
=> another type of user comes in and says "we can't use because you violate
spec"
=> two new versions of software must be released and maintained, one that
violates spec and one that doesn't

We must accept that hardware implementations exist which are set in stone.
"MUST NOT" for anything that was enabled by default, in new software, in
the last 10 years, is more or less a no-go.

With regard to key rollover, most users do not rollover keys in SSH. At all.

On Fri, Sep 15, 2017 at 10:28 AM, Salz, Rich <rsalz@akamai.com> wrote:

> ➢ Ok, so why can't that just be done the next time the deployed base is
> ready?  Is there a reason why the deployed base needs to be compliant with
> this RFC?  Or will making 2048 a MUST help to drive the change?
>
>
> That’s an excellent question; I think Dennis and other authors should
> reply ☺
>
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>