<div dir="ltr"><div>Thank you for looping us in -- my understanding is that &quot;Mobile SSH&quot; refers to a freeware Android app based on OpenSSH (<a href="https://play.google.com/store/apps/details?id=mobileSSH.feng.gao">https://play.google.com/store/apps/details?id=mobileSSH.feng.gao</a>) and the PuTTY terminal emulator. It&#39;s unrelated to Mosh (mobile shell).<br></div><div><br></div><div>Mosh doesn&#39;t implement any public-key cryptography.<br></div><div><br></div><div>Best regards all,</div><div>Keith</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 10, 2021 at 9:55 PM Mark D. Baushke &lt;<a href="mailto:mdb@juniper.net">mdb@juniper.net</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[To+ Ron, Alexandre, mosh-devel, Simon] question on rsa2048-sha256 KeX for SSH<br>
<br>
Summary:<br>
<br>
    Is anyone actively using rsa2048-sha256 for a Ssecure Shell Key<br>
    exchange per RFC 4432. <br>
<br>
    The Security Area Director Benjamin Kaduk has concerns regarding<br>
    this Key Exchange Algorithm (see messagess below).<br>
<br>
    The IETF Draft<br>
<br>
    <a href="https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/</a><br>
<br>
    is presently in Last Call.<br>
<br>
    This draft is in the process of suggesting &quot;MUST NOT&quot; for<br>
    rsa1024-sha1.<br>
<br>
    The question on the table is if the same rating should be appled to<br>
    rsa2048-sha256 or if RFC 4432 should itself be moved to historical,<br>
    or if this is still a useful key exchange being actively used.<br>
<br>
    Ben desires data and it is my suggestion that the supporters for the<br>
    implementations that provide for rsa2048-sha256 may information on<br>
    this topic.<br>
<br>
    Comments welcome.<br>
<br>
Hi Ben &amp; Peter,<br>
<br>
To Peter&#39;s question, my straw poll was explicitly about the *-sha1 Key<br>
Exchanges which did not include the rsa2048-sha256 kex.<br>
<br>
If I go to <a href="https://ssh-comparison.quendi.de/comparison/kex.html" rel="noreferrer" target="_blank">https://ssh-comparison.quendi.de/comparison/kex.html</a><br>
<br>
I see that rsa2048-sha256 is supported by the following implementations:<br>
<br>
   AsyncSSH   (maintained by Ron Frederick)<br>
   libassh    (maintained by Alexandre Becoulet)<br>
   Mobile SSH (aka Mosh via <a href="http://mosh.org" rel="noreferrer" target="_blank">mosh.org</a> and &lt;<a href="mailto:mosh-devel@mit.edu" target="_blank">mosh-devel@mit.edu</a>&gt;)<br>
              (original paper authors<br>
                   Keith Winstein &lt;<a href="mailto:keithw@mit.edu" target="_blank">keithw@mit.edu</a>&gt;,<br>
                   Hari Balakrishnan &lt;<a href="mailto:hari@mit.edu" target="_blank">hari@mit.edu</a>&gt;)<br>
   PuTTY      (maintained by Simon Tatham)<br>
<br>
There may be other implementations that are not in the comparison chart,<br>
but I think this may be a good start.<br>
<br>
I have added both Ron, Alexandre, <a href="mailto:mosh-devel@mit.edu" target="_blank">mosh-devel@mit.edu</a>, and Simon to the<br>
TO line for this message.<br>
<br>
Thank you for your participation in this thread.<br>
<br>
        Be safe, stay healthy,<br>
        -- Mark<br>
<br>
 ------- original messages -------<br>
<br>
Date: Wed, 10 Feb 2021 20:25:51 -0800<br>
From: Benjamin Kaduk &lt;<a href="mailto:kaduk@mit.edu" target="_blank">kaduk@mit.edu</a>&gt;<br>
To: <a href="mailto:curdle@ietf.org" target="_blank">curdle@ietf.org</a><br>
Archived-At: &lt;<a href="https://mailarchive.ietf.org/arch/msg/curdle/uo-OEckOhU8CKCzwwws6kKNsM2s" rel="noreferrer" target="_blank">https://mailarchive.ietf.org/arch/msg/curdle/uo-OEckOhU8CKCzwwws6kKNsM2s</a>&gt;<br>
Subject: [Curdle] RSA key transport for SSH (RFC 4432) and forward secrecy<br>
<br>
While reviewing draft-ietf-curdle-ssh-kex-sha2, I followed many of the<br>
references, which included RFC 4432, which defines the &quot;rsa1024-sha1&quot;<br>
(getting deprecated for SHA-1 usage) and &quot;rsa2048-sha256&quot; (which is not)<br>
key exchange methods.  While the specific construction is claimed to still<br>
produce contributory behavior in practice (due to the client-contributed<br>
key only ever being used in combination with the hash of server-provided<br>
data), it seems to still be the case that if the RSA private key is<br>
revealed, the session key is revealed, which is mostly the standard<br>
non-forward-secret behavior.<br>
<br>
Things are perhaps better if you buy into the theory that &quot;it may be a<br>
transient key generated solely for this SSH connection, or it may be<br>
re-used for several connections&quot; is supposed to prevent indefinite reuse of<br>
the RSA keypair, which seems ... not very reassuring.<br>
<br>
While it&#39;s not clear to me that there&#39;s specific reason to (say) move the<br>
whole RFC to Historic status or claim that it is obsoleted by some<br>
more-modern key-exchange method, it does seem likely to me that we could<br>
get IETF consensus that actually using rsa2048-sha256 is generally a bad<br>
idea.  (Or maybe we could get consensus to move it to Historic.)  Perhaps<br>
an RFC 2026 Applicability Statement would be an appropriate tool for this<br>
case?<br>
<br>
But most likely the best place to start would be to ask how widely it&#39;s<br>
implemented and if it&#39;s known to be in use anywhere...does anyone have<br>
data?<br>
<br>
Thanks,<br>
<br>
Ben<br>
<br>
_______________________________________________<br>
Curdle mailing list<br>
<a href="mailto:Curdle@ietf.org" target="_blank">Curdle@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/curdle" rel="noreferrer" target="_blank">https://www.ietf.org/mailman/listinfo/curdle</a><br>
<br>
 ------- message 2 -------<br>
<br>
From: Peter Gutmann &lt;<a href="mailto:pgut001@cs.auckland.ac.nz" target="_blank">pgut001@cs.auckland.ac.nz</a>&gt;<br>
To: Benjamin Kaduk &lt;<a href="mailto:kaduk@mit.edu" target="_blank">kaduk@mit.edu</a>&gt;, &quot;<a href="mailto:curdle@ietf.org" target="_blank">curdle@ietf.org</a>&quot; &lt;<a href="mailto:curdle@ietf.org" target="_blank">curdle@ietf.org</a>&gt;<br>
Date: Thu, 11 Feb 2021 04:47:07 +0000<br>
Archived-At: &lt;<a href="https://mailarchive.ietf.org/arch/msg/curdle/vwS-A4E04Mg1A8avNfWqaXtZli0" rel="noreferrer" target="_blank">https://mailarchive.ietf.org/arch/msg/curdle/vwS-A4E04Mg1A8avNfWqaXtZli0</a>&gt;<br>
Subject: Re: [Curdle] RSA key transport for SSH (RFC 4432) and forward<br>
 secrecy<br>
<br>
Benjamin Kaduk &lt;<a href="mailto:kaduk@mit.edu" target="_blank">kaduk@mit.edu</a>&gt; writes:<br>
<br>
&gt;But most likely the best place to start would be to ask how widely it&#39;s<br>
&gt;implemented and if it&#39;s known to be in use anywhere...does anyone have data?<br>
<br>
We could start with Mark Baushke&#39;s KEX straw poll from a month ago, I think<br>
pretty much everyone voted RSA a MUST NOT which would indicate that no-one&#39;s<br>
going to miss it.<br>
<br>
Peter.<br>
<br>
<br>
_______________________________________________<br>
Curdle mailing list<br>
<a href="mailto:Curdle@ietf.org" target="_blank">Curdle@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/curdle" rel="noreferrer" target="_blank">https://www.ietf.org/mailman/listinfo/curdle</a><br>
<br>
 ------- end of original messages -------<br>
</blockquote></div>