Re: Terrapin

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

On Wed, Dec 20, 2023, 14:57 Niels M=C3=B6ller <[email protected]> wrote:

>
> Mouse <[email protected]> writes:
>
> > Except, of course, that the receiver can't take it that way unless the
> > sender is known to always send it.  I haven't come up with a good way
> > to ensure that without a protocol change.
>
> I'd be happy with a version 2.1 for that (and with other backwards
> compatible counter measures until that is deployed). But perhaps one can
> use the same hack as for extensions (rfc8308), to add a magic indicator
> to the kex_algorithms_list?
>
> > The closest I have come up with is for each end to send an extension
> > request as its first post-kex packet and expect a response of *some*
> > kind to it before doing anything further.
>
> Yoy shouldn't need an extension, a nop global request would do? It will
> cost a roundtrip if you wait for the response. If I understand this
> right, each party will only be able to add this protection to one of the
> directions, right?


I don't think there needs to be any request. Consider an extension which
neither adds new messages nor changes the form of any existing message.
Instead, any time both parties have advertised the extension in the
kex_algorithns list, the semantics of NEWKEYS are changed such that the
sequence numbers are reset in a defined way.

-- Jeff

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

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Wed, Dec 20, 2023, 14:57 Niels M=C3=B6ller &lt;<a h=
ref=3D"mailto:[email protected]" target=3D"_blank" rel=3D"noreferrer">ni=
[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
br>
Mouse &lt;[email protected]&gt; writes:<br>
<br>
&gt; Except, of course, that the receiver can&#39;t take it that way unless=
 the<br>
&gt; sender is known to always send it.=C2=A0 I haven&#39;t come up with a =
good way<br>
&gt; to ensure that without a protocol change.<br>
<br>
I&#39;d be happy with a version 2.1 for that (and with other backwards<br>
compatible counter measures until that is deployed). But perhaps one can<br=
>
use the same hack as for extensions (rfc8308), to add a magic indicator<br>
to the kex_algorithms_list?<br>
<br>
&gt; The closest I have come up with is for each end to send an extension<b=
r>
&gt; request as its first post-kex packet and expect a response of *some*<b=
r>
&gt; kind to it before doing anything further.<br>
<br>
Yoy shouldn&#39;t need an extension, a nop global request would do? It will=
<br>
cost a roundtrip if you wait for the response. If I understand this<br>
right, each party will only be able to add this protection to one of the<br=
>
directions, right?</blockquote></div></div><div dir=3D"auto"><br></div><div=
 dir=3D"auto">I don&#39;t think there needs to be any request. Consider an =
extension which neither adds new messages nor changes the form of any exist=
ing message. Instead, any time both parties have advertised the extension i=
n the kex_algorithns list, the semantics of NEWKEYS are changed such that t=
he sequence numbers are reset in a defined way.</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">-- Jeff=C2=A0</div></div>

--00000000000096cfef060d0fd3ca--