Subject: [Curdle] RSA key transport for SSH (RFC 4432) and forward secrecy

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 10 Feb 2021 20:25:51 -0800

While reviewing draft-ietf-curdle-ssh-kex-sha2, I followed many of the
references, which included RFC 4432, which defines the "rsa1024-sha1"
(getting deprecated for SHA-1 usage) and "rsa2048-sha256" (which is not)
key exchange methods.  While the specific construction is claimed to still
produce contributory behavior in practice (due to the client-contributed
key only ever being used in combination with the hash of server-provided
data), it seems to still be the case that if the RSA private key is
revealed, the session key is revealed, which is mostly the standard
non-forward-secret behavior.

Things are perhaps better if you buy into the theory that "it may be a
transient key generated solely for this SSH connection, or it may be
re-used for several connections" is supposed to prevent indefinite reuse of
the RSA keypair, which seems ... not very reassuring.

While it's not clear to me that there's specific reason to (say) move the
whole RFC to Historic status or claim that it is obsoleted by some
more-modern key-exchange method, it does seem likely to me that we could
get IETF consensus that actually using rsa2048-sha256 is generally a bad
idea.  (Or maybe we could get consensus to move it to Historic.)  Perhaps
an RFC 2026 Applicability Statement would be an appropriate tool for this
case?

But most likely the best place to start would be to ask how widely it's
implemented and if it's known to be in use anywhere...does anyone have
data?

Thanks,

Ben

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 11 Feb 2021 04:47:07 +0000

Benjamin Kaduk <[email-masked]> writes:
 
>implemented and if it's known to be in use anywhere...does anyone have data?

We could start with Mark Bauschke's KEX straw poll from a month ago, I think
pretty much everyone voted RSA a MUST NOT which would indicate that no-one's
going to miss it.

Peter.

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 10 Feb 2021 21:50:58 -0800

[To+ Ron, Alexandre, mosh-devel, Simon] question on rsa2048-sha256 KeX for SSH

Summary:

    Is anyone actively using rsa2048-sha256 for a Ssecure Shell Key
    exchange per RFC 4432. 

    The Security Area Director Benjamin Kaduk has concerns regarding
    this Key Exchange Algorithm (see messagess below).

    The IETF Draft

    https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/

    is presently in Last Call.

    This draft is in the process of suggesting "MUST NOT" for
    rsa1024-sha1.

    The question on the table is if the same rating should be appled to
    rsa2048-sha256 or if RFC 4432 should itself be moved to historical,
    or if this is still a useful key exchange being actively used.

    Ben desires data and it is my suggestion that the supporters for the
    implementations that provide for rsa2048-sha256 may information on
    this topic.
    
    Comments welcome.

Hi Ben & Peter,

To Peter's question, my straw poll was explicitly about the *-sha1 Key
Exchanges which did not include the rsa2048-sha256 kex.

If I go to https://ssh-comparison.quendi.de/comparison/kex.html

I see that rsa2048-sha256 is supported by the following implementations:

   AsyncSSH   (maintained by Ron Frederick)
   libassh    (maintained by Alexandre Becoulet)
   Mobile SSH (aka Mosh via mosh.org and <[email-masked]>)
              (original paper authors
   	      	   Keith Winstein <[email-masked]>,
		   Hari Balakrishnan <[email-masked]>)
   PuTTY      (maintained by Simon Tatham)

There may be other implementations that are not in the comparison chart,
but I think this may be a good start.

I have added both Ron, Alexandre, [email-masked], and Simon to the
TO line for this message.

Thank you for your participation in this thread.

	Be safe, stay healthy,
	-- Mark

 ------- original messages -------

Date: Wed, 10 Feb 2021 20:25:51 -0800
From: Benjamin Kaduk <[email-masked]>
To: [email-masked]
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/uo-OEckOhU8CKCzwwws6kKNsM2s>
Subject: [Curdle] RSA key transport for SSH (RFC 4432) and forward secrecy

Thanks,

Ben

_______________________________________________
Curdle mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/curdle

 ------- message 2 -------

From: Peter Gutmann <[email-masked]>
To: Benjamin Kaduk <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 11 Feb 2021 04:47:07 +0000
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/vwS-A4E04Mg1A8avNfWqaXtZli0>
Subject: Re: [Curdle] RSA key transport for SSH (RFC 4432) and forward
 secrecy

>implemented and if it's known to be in use anywhere...does anyone have data?

We could start with Mark Baushke's KEX straw poll from a month ago, I think
pretty much everyone voted RSA a MUST NOT which would indicate that no-one's
going to miss it.

Peter.

_______________________________________________
Curdle mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/curdle

 ------- end of original messages -------

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 11 Feb 2021 05:57:16 +0000

>I see that rsa2048-sha256 is supported by the following implementations:

Of those, mosh and Putty are client only so presumably they only do it for
compatibility purposes.  Possibly a more useful form of the poll would be
"which servers still rely on RSA?".

Peter.

---

From: Keith Winstein <[email-masked]>
Date: Wed, 10 Feb 2021 22:01:36 -0800

Thank you for looping us in -- my understanding is that "Mobile SSH" refers
to a freeware Android app based on OpenSSH (
https://play.google.com/store/apps/details?id=mobileSSH.feng.gao) and the
PuTTY terminal emulator. It's unrelated to Mosh (mobile shell).

Mosh doesn't implement any public-key cryptography.

Best regards all,
Keith

On Wed, Feb 10, 2021 at 9:55 PM Mark D. Baushke <[email-masked]> wrote:

> Archived-At: <
> https://mailarchive.ietf.org/arch/msg/curdle/uo-OEckOhU8CKCzwwws6kKNsM2s>
> Archived-At: <
> https://mailarchive.ietf.org/arch/msg/curdle/vwS-A4E04Mg1A8avNfWqaXtZli0>

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 10 Feb 2021 22:12:14 -0800

[moved to BCC: [email-masked], 
               Hari Balakrishnan <[email-masked]>, [email-masked],]

Hi Keith,

It seems I had the wrong pointer for Mobile SSH. Thank you for the
correction.

	Be safe, stay healthy,
	-- Mark

---

From: Ron Frederick <[email-masked]>
Date: Wed, 10 Feb 2021 22:27:55 -0800

>    implementations that provide for rsa2048-sha256 may information on

I added rsa1024-sha1 and rsa2048-sha256 to AsyncSSH back in 2018 to improve compatibility after noticing that there were other implementations out there. Since then, based on discussions on this mailing list, I disabled rsa1024-sha1 by default, but still allow it to be used if explicitly enabled. At this point, rsa2048-sha256 remains enabled in AsyncSSH, but it’s the very last entry in the list of advertised kex algorithms by default.

Depending on the outcome of this discussion, I would be happy to consider disabling both algorithms by default. I don’t see a reason in most cases to prefer them over other more widely implemented kex algorithms. However, I’d probably leave them available just in case someone wanted to use them.

One scenario which comes to mind where these algorithms could provide a benefit is precisely in the case which led to this thread suggesting we disable them, where someone might want the ability to passively monitor a stream and compute the session key when given the RSA private key. This is not possible (by design) with other kex algorithms without becoming an active man-in-the-middle, but it could be done passively with these RSA-based kex algorithms. I know such tools exist for TLS, but I don’t know if anyone has built something like that for SSH.
-- 
Ron Frederick
[email-masked]

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 11 Feb 2021 11:21:39 -0800

Hi Mark,

>     this Key Exchange Algorithm (see messagess below).

That perhaps came across stronger than I had hoped for -- AFAIK the RFC
does what it says to do and says what it does; it's just that what it does
may no longer reflect what the IETF currently considers to be best
practices, and I'm pondering how we might go about recording that in some
official-ish way.

>     or if this is still a useful key exchange being actively used.

To clarify: my intent and expectation was that we consider this question
separately from the advancement of draft-ietf-curdle-ssh-kex-sha2.  We may
want to think on this question for a while, and that draft is otherwise in
good shape and shouldn't be further held up.

>     implementations that provide for rsa2048-sha256 may information on

Indeed, and thanks for all the responses received so far.

-Ben

---

From: Simon Tatham <[email-masked]>
Date: Fri, 12 Feb 2021 14:23:57 +0000

> Is anyone actively using rsa2048-sha256 for a Ssecure Shell Key

I passed this question on to Ben Harris, also on the PuTTY team and the
originator of RFC 4432 in the first place (hence, the person most likely
to have actually used it seriously). He replied

"No. It never became adequately mainstream, and faster CPUs and elliptic
curves have rendered it obsolete."

So I think the PuTTY team has no objection to retiring it.

Cheers,
Simon

-- 
for k in [pow(x,37,0x1a1298d262b49c895d47f) for x in [0x50deb914257022de7fff,
0x213558f2215127d5a2d1, 0x90c99e86d08b91218630, 0x109f3d0cfbf640c0beee7,
0xc83e01379a5fbec5fdd1, 0x19d3d70a8d567e388600e, 0x534e2f6e8a4a33155123]]:
 print("".join([chr(32+3*((k>>x)&1))for x in range(79)])) # <[email-masked]>