Re: Async rekey?

[Simon Tatham <anakin%pobox.com@localhost>]

Mouse  <mouse%Rodents-Montreal.ORG@localhost> wrote:
> I looked through the specs, and in 4253, starting about 2/3 of the way
> through page 19, I found text saying that
> 
>    Once a party has sent a SSH_MSG_KEXINIT message for key exchange or
>    re-exchange, until it has sent a SSH_MSG_NEWKEYS message (Section
>    7.3), it MUST NOT send any messages other than: [...]
> 
> I don't recall why this was done (nor indeed whether it was even
> discussed).  It makes sense for initial kex, but it doesn't strike me
> as conceptually necessary for rekeying.

One useful feature of this is that it provides detection and intolerance
of implementations that forget to rekey at all.

If (a hypothetical) AliceSSH disregards this part of the spec, while
talking to the newly written (and equally hypothetical) BobSSH which
accidentally drops the incoming KEXINIT on the floor, then everything
will carry on 'working', nobody will notice, and the rekey will remain
pending forever - but, unknown to the user, an important safeguard has
gone missing.

But if AliceSSH stops sending any useful packets, then it won't take
BobSSH's developer (or first user to test against something that isn't
another BobSSH) very long at all to notice that something is wrong, and
report a bug!

(And even if BobSSH is too lazy to actually fix the bug, so that the end
user has no option but to set a bug-compatibility flag in AliceSSH that
prevents it from even trying to rekey, then at least they _know_ they're
not getting their keys renewed, and can take care to keep connections
short.)

I actually missed this in the spec myself, and implemented it in PuTTY
*anyway* because I'd independently decided it was a good idea for this
reason!

> Would there be any interest in relaxing this, so that data exchange can
> continue in parallel with rekey computation?  Or has someone already
> done that?  (I don't recall hearing of any, but that means little.)

I think you'd still need _some_ means of putting pressure on the other
party to actually get round to handling the KEXINIT sooner or later, or
detecting if it persistently doesn't.

-- 
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)])) # <anakin%pobox.com@localhost>

-- 
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)])) # <anakin%pobox.com@localhost>