IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Binary packet protocol rethink



Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost> writes:

> Niels Möller <nisse%lysator.liu.se@localhost> writes:
>
>>One can do all of these with the current ssh wire protocol. It's even
>>straight-forward to do. But if we switch to clear text lengths (with no
>>other, deeper, changes to the protocol), it gets a lot more difficult.
>
> Why?  The length just tells you how much to decrypt in one block, what you put
> inside it is up to you.

With the current protocol, I must encrypt exactly one SSH message, hence
cleartext lengths reveal number of SSH messages, and their lengths. TCP
headers need *not* be so correlated.

> At a lower level, the TCP headers already give length information, and
> if you can deal with that then you can just as easily deal with
> plaintext lengths.

The ssh implementation generates a sequence of cleartext messages to be
transported across the network.

The ssh transport machinery can encrypt these, then split them into
fixed size blocks and send off with pre-determined intervals, and
whatever else you think is a useful counter measure to traffic analysis.
When an input message or message fragment is too short, insert ignore
messages (preferable in *front* of the real data, for the byte-by-byte
dribble attack).

I'm happy to discuss the tradeoffs here, but it seems that you keep
repeating that the attacker gets as much useful info from observing tcp
segment boundaries as from observing ssh message boundaries. I don't
think that is correct description of the current protocol, and it seems
our disagreement on this point kind-of blocks useful discussion.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.



Home | Main Index | Thread Index | Old Index