Re: Binary packet protocol rethink

[nisse%lysator.liu.se@localhost (Niels Möller)]

Simon Tatham <anakin%pobox.com@localhost> writes:

> Is there any possible way - and would people be interested in pursuing
> it if there were - to invent a replacement binary packet protocol for
> SSH which decouples the unit of encryption and the unit of protocol
> semantics into completely separate layers?

I think it's interesting to explore, but I'm not sure it's possible to
get it much better than the ssh protocol with careful use of IGNORE
packets.

The problem is the interactivity. Let's consider the simplest example
(but I'm not saying this example captures all essentials of the
problem). Say I let my shell connection idle for some time, then I type
a couple of characters, and I want a timely response before I type the
next command. Then my typing has to correspond to a TCP segment that can
be decrypted and authenticated and passed on to the remote shell. With
the current ssh protocol, that TCP segment will carry a single
CHANNEL_DATA packet, possibly in combination with fragments of IGNORE
messages and possibly other piggybacking messages, e.g., WINDOW_ADJUST.

To hide the user's typing from traffic analysis is a tradeoff, with
varying amounts of cover traffic (preferably including responses;
there's maybe some use for an IGNORE_CONTENTS_BUT_PLEASE_REPLY message
type). It's highly desirable to hide details of the user's typing; some
reasonable counter measures are to collect keystrokes for a few 100 ms
before generating any packet, and use padding to hide the number of
keystrokes included in each packet.

> And even if you encrypt the length field in a way
> that avoids that mistake, you still don't reliably hide your _padded_
> packet lengths anyway, in the face of an active attacker who can proxy
> the TCP stream, dribble it out a byte at a time, and wait to see which
> byte triggers a response. I suspect some defensive uses of
> SSH_MSG_IGNORE may still have this issue.

This is a good point which is easy to overlook. The lesson here is that
it is better to add the padding data at the start of the TCP segment
rather than at the end; the boundary between initial padding and the
start of the message is *not* revealed by the dribbel attack. And we
should also keep in mind that there are relevant attackers which are
only passive eavesdroppers, so a defense which is effective only against
passive adverseries but fails with an active adversary still has value.

For design of a cryptographic transport protocol, interactivity implies
that there has to be some kind of flush/sync mechanism. The input can't
be just a cleartext byte stream, it has to be a byte stream with
syncronization points. A syncronization point means that data up to that
point must be delivered without waiting for further input. So the
cryptographic transport protocol must encrypt it, send it out on the
wire in a timely manner, and attach an authentication tag and any other
signalling needed for the receiver to decrypt, authenticate, and process
the data. Which breaks a pure separation between layers.

And those synchronization points are going to be revealed by the dribble
attack.

One possible design would be to make the block of the crypto layer a
fixed size, say around 200 bytes, and then to get a synchronization
point, just insert an ignore message of at least 200 bytes (possibly
with randomized larger size). Probably not a good idea for a general
purpose crypto protocol, though.

> I've always thought a good way to solve this _in principle_ would be to
> replace our current all-in-one message/packet structure with two
> independent layers.

It's long time since I looked into the details of TLS, but doesn't it
have more of this kind of separation? How does it handle the
syncronization issue?

> Is this an idea that appeals to anyone else?

I definitely see the appeal, but I'm a bit skeptic that it can work out.

Regards,
/Niels

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