[mosh-devel] [Curdle] RSA key transport for SSH (RFC 4432) and forward secrecy

[Keith Winstein]

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 <mdb at juniper.net> wrote:

> [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 <mosh-devel at mit.edu>)
>               (original paper authors
>                    Keith Winstein <keithw at mit.edu>,
>                    Hari Balakrishnan <hari at mit.edu>)
>    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, mosh-devel at mit.edu, 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 <kaduk at mit.edu>
> To: curdle at ietf.org
> Archived-At: <
> https://mailarchive.ietf.org/arch/msg/curdle/uo-OEckOhU8CKCzwwws6kKNsM2s>
> Subject: [Curdle] RSA key transport for SSH (RFC 4432) and forward secrecy
>
> 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
>
> _______________________________________________
> Curdle mailing list
> Curdle at ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>
>  ------- message 2 -------
>
> From: Peter Gutmann <pgut001 at cs.auckland.ac.nz>
> To: Benjamin Kaduk <kaduk at mit.edu>, "curdle at ietf.org" <curdle at ietf.org>
> 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
>
> Benjamin Kaduk <kaduk at mit.edu> writes:
>
> >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?
>
> 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
> Curdle at ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>
>  ------- end of original messages -------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20210211/08edf6d3/attachment.html