Re: Terrapin

--000000000000f8e161060d2d4bff
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Related publication at NIST:
https://nvd.nist.gov/vuln/detail/CVE-2023-48795

References the Terrapin attack and implementations/versions that are
identified as vulnerable.

Implementation versions that are identified as NOT VULNERABLE have all
recently implemented "strict key exchange"

I wasn't aware we already had a solution for this....

Thoughts?

Brian Pence
Celestial Software
901-283-1970 <http://voice.google.com/calls?a=3Dnc,%2B19012831970>
http://www.celestialsoftware.net


On Fri, Dec 22, 2023 at 11:00=E2=80=AFAM Mouse <[email protected]>=
 wrote:

>
> > 1. We need to get a clear statement of just how big a deal this
> >    really is, not in theory, but in practice.  AFAICT it's more
> >    checkered-trouser-time than brown-trowser-time.
>
> Well, there are known workarounds.  That helps.
>
> > 2. The problem isn't in the SSH protocol but in a third-party add-on
> >    to it, which means the simple fix is just "don't do that, then",
>
> Eh, I disagree.
>
> Prefix truncation is a weakness in the BPP as it is currently defined.
> Whether that weakness is exploitable now or not, it really should be
> fixed.  (It currently appears to be exploitable in some, but only some,
> circumstances.)
>
> So there are two problems here.  The first is that there is a crypto
> weakness in the early phases of the BPP; the second is that EXT_INFO
> renders the first one relatively easy to exploit.  I don't think it's
> fair to call either one a third-party add-on.
>
> EtM crypto, which is much more of a third-party thing, makes prefix
> truncation significantly easier to carry out, but all that does is
> convert the (already far too high) success probability into 100%.
>
> And, all that aside, while it may not be exploitable at present without
> EXT_INFO, I really do think it is an extremely bad idea for BPP's
> security to depend on details of what is layered atop it.
>
> > 3. The long-term fix is to create an IETF-standardised EtM mechanism
> >    to replace the third-party one.
>
> Again, I disagree.  Anything that leads to sending packet lengths in
> the clear will make prefix truncation trivially easy.
>
> So any such mechanism will be a lose _unless_ it is coupled with fixing
> the other issues: the lack of sequence number reset (or sequence number
> verification - it would work as well for the first packet after NEWKEYS
> to be a verifier that carries each side's idea of the current sequence
> number, protected by the negotiated crypto).
>
> >    For this I'd say it should hash the full handshake transcript not
> >    just the current practice
>
> That could help significantly, though it would have to be done right.
> If the modified protocol has the potential for traffic to occur between
> the last point the hash covers and the NEWKEYS, that possible traffic
> needs very close attention; if not, correct handling (probably meaning
> "rejection") of any such attempted traffic needs to be emphasized as
> critical to security.
>
> /~\ The ASCII                             Mouse
> \ / Ribbon Campaign
>  X  Against HTML                [email protected]
> / \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
>

--000000000000f8e161060d2d4bff
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Related publication at NIST:</div><div><a href=3D"htt=
ps://nvd.nist.gov/vuln/detail/CVE-2023-48795">https://nvd.nist.gov/vuln/det=
ail/CVE-2023-48795</a><br></div><div><br></div><div>References the Terrapin=
=C2=A0attack and implementations/versions that are identified as vulnerable=
.</div><div><br></div><div>Implementation versions that are identified as N=
OT VULNERABLE have all recently implemented &quot;strict key exchange&quot;=
</div><div><br></div><div>I wasn&#39;t aware we already had a solution for =
this....</div><div><br></div><div>Thoughts?</div><br clear=3D"all"><div><di=
v dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature">=
<div dir=3D"ltr"><div>Brian Pence</div><div>Celestial Software</div><div>90=
1-283-1970<a href=3D"http://voice.google.com/calls?a=3Dnc,%2B19012831970" c=
lass=3D"gv-tel-link" target=3D"_blank" rel=3D"noopener" title=3D"Call +1 90=
1-283-1970 via Google Voice"></a></div><div><a href=3D"http://www.celestial=
software.net" target=3D"_blank">http://www.celestialsoftware.net</a></div><=
/div></div></div><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Fri, Dec 22, 2023 at 11:00=E2=80=AFAM Mouse &lt;<a =
href=3D"mailto:[email protected]">[email protected]</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
&gt; 1. We need to get a clear statement of just how big a deal this<br>
&gt;=C2=A0 =C2=A0 really is, not in theory, but in practice.=C2=A0 AFAICT i=
t&#39;s more<br>
&gt;=C2=A0 =C2=A0 checkered-trouser-time than brown-trowser-time.<br>
<br>
Well, there are known workarounds.=C2=A0 That helps.<br>
<br>
&gt; 2. The problem isn&#39;t in the SSH protocol but in a third-party add-=
on<br>
&gt;=C2=A0 =C2=A0 to it, which means the simple fix is just &quot;don&#39;t=
 do that, then&quot;,<br>
<br>
Eh, I disagree.<br>
<br>
Prefix truncation is a weakness in the BPP as it is currently defined.<br>
Whether that weakness is exploitable now or not, it really should be<br>
fixed.=C2=A0 (It currently appears to be exploitable in some, but only some=
,<br>
circumstances.)<br>
<br>
So there are two problems here.=C2=A0 The first is that there is a crypto<b=
r>
weakness in the early phases of the BPP; the second is that EXT_INFO<br>
renders the first one relatively easy to exploit.=C2=A0 I don&#39;t think i=
t&#39;s<br>
fair to call either one a third-party add-on.<br>
<br>
EtM crypto, which is much more of a third-party thing, makes prefix<br>
truncation significantly easier to carry out, but all that does is<br>
convert the (already far too high) success probability into 100%.<br>
<br>
And, all that aside, while it may not be exploitable at present without<br>
EXT_INFO, I really do think it is an extremely bad idea for BPP&#39;s<br>
security to depend on details of what is layered atop it.<br>
<br>
&gt; 3. The long-term fix is to create an IETF-standardised EtM mechanism<b=
r>
&gt;=C2=A0 =C2=A0 to replace the third-party one.<br>
<br>
Again, I disagree.=C2=A0 Anything that leads to sending packet lengths in<b=
r>
the clear will make prefix truncation trivially easy.<br>
<br>
So any such mechanism will be a lose _unless_ it is coupled with fixing<br>
the other issues: the lack of sequence number reset (or sequence number<br>
verification - it would work as well for the first packet after NEWKEYS<br>
to be a verifier that carries each side&#39;s idea of the current sequence<=
br>
number, protected by the negotiated crypto).<br>
<br>
&gt;=C2=A0 =C2=A0 For this I&#39;d say it should hash the full handshake tr=
anscript not<br>
&gt;=C2=A0 =C2=A0 just the current practice<br>
<br>
That could help significantly, though it would have to be done right.<br>
If the modified protocol has the potential for traffic to occur between<br>
the last point the hash covers and the NEWKEYS, that possible traffic<br>
needs very close attention; if not, correct handling (probably meaning<br>
&quot;rejection&quot;) of any such attempted traffic needs to be emphasized=
 as<br>
critical to security.<br>
<br>
/~\ The ASCII=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mouse<br>
\ / Ribbon Campaign<br>
=C2=A0X=C2=A0 Against HTML=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 <a href=3D"mailto:[email protected]" target=3D"_blank">mous=
[email protected]</a><br>
/ \ Email!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A07D C8 61 52 5D E7 2D 39=
=C2=A0 4E F1 31 3E E8 B3 27 4B<br>
</blockquote></div>

--000000000000f8e161060d2d4bff--