Re: Terrapin

[Niels Möller <nisse%lysator.liu.se@localhost>]

Mouse <mouse%Rodents-Montreal.ORG@localhost> writes:

> No, or at least not in theory; an attacker active enough to mount a
> prefix truncation attack could easily enough edit it out of the kex
> algorithm list.

I don't think so, the kexinit packet is protected (included in the
exchange hash), that's intended to protect against any manipulation of
what's advertised in the kexinit?

Looking over the RFC 4253, it should also be possibly to introduce a
NEWKEYS2 without breaking backwards compatibility. One should expect
either a proper ack (however we define that), or a UNIMPLEMENTED
response. But I'd imagine responding with UNIMPLEMENTED is a code path
that's not well tested in implementations...

In theory, one could maybe devise a way to send a NEWKEYS2 *instead* of
NEWKEYS, with some new semantics. One would then expect either a
UNIMPLEMENTED response, in which case one would fall back to sending an
old-style NEWKEYS, or a NEWKEYS2 for the other direction, which would
imply that the other side supports NEWKEYS2, and one can start sending
packets according to the new semantics. As I read end of 7.1 and 11, it
looks like that is an intended possibility for protocol additions
(although this variant costs a roundtrip, until we define a v2.1
protocol where NEWKEYS2 is mandatory). Would be curious to explore
how badly it breaks current implementations. 

>> Yoy shouldn't need an extension, a nop global request would do?
>
> Hmm.
>
> I'd have to think more.  I think a NOP global request should be as good
> as an extension request - but is there such a thing, or would that
> require a protocol revision?

I was confused, I was thinking of connection-layer global request, but
that's not valid at this point.

On the other hand, I'd expect SERVICE_REQUEST/SERVICE_ACCEPT to be the
first messages after NEWKEYS (except if there are IGNORE or DEBUG
packets in between, deletion of which aren't that critical), so I don't
get how an attacker deleting one of those wouldn't terminate the
connection; I guess I have to read the paper. Is the issue that
implementations doing EXT_INFO sends those packets between NEWKEYS and
SERVICE_*, making those packet vulnerable to the attack?

> Also, to really work fully right, SSH_NEWKEYS2 really should contain
> something that requires knowing kex output, so it can't be a replay at
> any level.

It comes with mac that depends on the kex output, I think that should be
enough?

>> 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?
>
> Sort of.  To add protection to the A->B direction, A has to send the
> packet and B has to check that it's (a) there and (b) the first
> post-kex packet.

The way I think of it, if the sender sends a specific packet immediately
after NEWKEYS, and gets some kind of ack, then the sender knows that
there's no "prefix truncation" on that direction. (Receiver doesn't get
any certainty, but arguably receiver doesn't need any, since it's the
sender that has an interest in getting their packets through).

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.