Subject: RE: Binary packet protocol rethink

From: Peter Gutmann <[email-masked]>
Date: Wed, 2 Dec 2015 01:09:33 +0000

Niels Möller <[email-masked]> writes:

>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).

The important point there is that it *can*, not that it actually *does*.  I've
heard that there was an OpenSSH patch some years ago that did something like
this, but in about 15 years of interop-testing my code I've never seen any
evidence that the other side is applying any traffic-analysis countermeasures.
A quick Google turns up this blog post from a few months ago:

http://malwaremusings.com/2015/07/13/traffic-analysis-openssh-with-an-interactive-shell/

which indicates that OpenSSH doesn't implement traffic-analysis protection
(not trying to single out OpenSSH here, but that seems to have the most bells
and whistles added to it so if it was implemented I'd sort of expect to see it
there first), and that some random guy with a copy of Wireshark (not an
intelligence agency, if that's what the perceived threat is) doesn't have much
problem in doing traffic analysis on it.

So there appears to be either zero or close to zero support out there for
anti-traffic-analysis.  Even if, say, OpenSSH were to add support, that would
only affect two similar OpenSSH implementations talking to each other.  As
soon as you get a single other SSH implementation involved (and there are a
lot of them out there), you lose the anti-traffic analysis.

>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.

At the moment it seems they do.  Unless actual, real countermeasures to
traffic analysis are actively applied by as many SSH implementations as
possible, encrypting the headers does nothing more than inconvenience
implementers.

So, let's turn this around: Show me evidence of assorted SSH implementations
performing anti-traffic-analysis measures, and then we can debate whether
encrypting the length hinders those countermeasures.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 2 Dec 2015 03:18:29 +0000

I wrote:

>and then we can debate whether encrypting the length hinders those
>countermeasures

Sorry, missing negation, that should be "not encrypting the length".

(See also my post to the TLS list today on how to progress this issue,
unfortunately the debate is by now spread across three lists, SSH, TLS, and
CFRG).

Peter.

---

From: [email-masked] (Niels Möller)
Date: Tue, 01 Dec 2015 13:31:05 +0100

Bryan Ford <[email-masked]> writes:

> It’s hard for me to see how separately authenticating the length field
> would be a benefit; in fact I would worry about whether it could
> introduce a weakness, e.g., where an attacker could somehow contrive
> “mix-and-match” attacks

I'm also not sure there's a real benefit. If we do it, the length and
payload data must be securely linked together. E.g., using a single
incrementing sequence of nonces. And it *may* be worthwhile to do
something with a short and therefore relatively weak authentication tag.

> Thus, changing the header encoding while leaving the authentication
> and body-encryption unchanged from standard AEAD practice cannot make
> security any worse than just transmitting the header (AD part) in
> cleartext, and can (sometimes) be a security benefit.

This is a clear argument. For this to hold, it's crucial that the length
encryption and the payload encryption are independent. In SSH, there's
been subtle problem when encrypting length and payload together using
CBC (I don't quite grasp the fine details, but there have been
references posted to the list recently).

> SSH, which did something like this, ran into trouble with attackers
> being able to twiddle the record length field to make the record length
> look big, causing the receiver to try to receive a very large record,
> and hence appear to the user to hang,

I don't think we have had this particular problem; any reasonable ssh
implementation ought to disconnect with a protocol error if the length
is unexpectedly large. Lengths are maximum 32K (unless both ends have
negotiated something different, which I think is rare).

There have been problems, but of a more subtle kind. Like observing when
and how the other end disconnect to get partial information about the
decryption, and in addition, infer information about the preceding
cleartext block thanks to the CBC relation.

> The conceptually simplest approach I can think of: In the specification
> of how AEAD nonces are generated (section 5.2.2 of
> draft-ietf-tls-tls13-07), reserve the least-significant bit of the
> record sequence number, so that sequence numbers increment by 2 rather
> than 1 each record.  Thus, we get two unique nonces per record from the
> same set of symmetric keys.  We first use the nonce with a '0'
> least-significant bit to perform the regular AEAD-encryption of the
> record with the header info as additional_data.

I think I'd use them in the opposite order (to get the sequence numbers
in processing order; one has to process the lengths first, in particular
on the decryption side), but that's a very minor detail.

I like the alternating nonces idea.

> Then for the same record we use the nonce with a '1' least-significant
> to AEAD-encrypt a sequence of five zero bytes ("\0\0\0\0\0"), and use
> the first five bytes of result as the cipherstream to XOR the 5-byte TLS
> header with before transmitting.

I think AEAD constructions of practical importance generate a key stream
and xor it to the plaintext. In which case your proposal (as I'm sure
you intended) boils down to generating a key stream with a different
nonce than for the payload.

Not sure if doing a "general" construction on top of an arbitrary AEAD
is useful; the alternative would be to leave the details to the
specification of any particular aead suite.

We're kind of ending up with "authenticated encryption with auxillary
authenticated data and auxillary encrypted data". That's going to be a
really awful acronym.

Regards,
/Niels

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

---

From: [email-masked] (Niels Möller)
Date: Wed, 02 Dec 2015 12:41:19 +0100

Peter Gutmann <[email-masked]> writes:

> performing anti-traffic-analysis measures,

I implemented the type of hiding we're discussing almost a decade ago,
and I'm using it daily. Now, I'm not working on lsh as actively these
days as I'd like, but I'd really like this part to get better, not
worse.

If most other implementations don't care, that's unfortunate. I'm sure
we could learn to do this quite well.

Regards,
/Niels

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 2 Dec 2015 23:23:27 +0000

Niels Möller <[email-masked]> writes:

>I implemented the type of hiding we're discussing almost a decade ago, and 
>I'm using it daily. Now, I'm not working on lsh as actively these days as 
>I'd like, but I'd really like this part to get better, not worse.

Ah, so it was lsh, not OpenSSH, my bad.  It'd be interesting to get some 
guidance on what works and what doesn't, for example if you're doing bulk
file transfers it's easy enough to traffic-shape (and my code does that
if possible, mostly to optimise network performance), but when you get into
things like interactive traffic or variable-size messages that have to be
sent right now (e.g. alerts/logging data), there's not much you can do
beyond padding it.

In addition a lot of SSH is produced as add-on libraries, for which the 
traffic being passed is opaque (and it's the same for TLS).  So the
traffic-shaping needs to be controlled by the developer that's using the 
library, not the library author, and that's probably not going to happen.
One side can't take responsibility for the issue, and the other side
doesn't want to because they have more pressing things to deal with.

I'm not aware of any comprehensive analysis/guidance on dealing with these
issues...

Peter.

---

From: Bryan Ford <[email-masked]>
Date: Wed, 2 Dec 2015 10:30:58 +0100

> lot of them out there), you lose the anti-traffic analysis.

That’s only the case with your approach of leaving all headers (SSH or TLS) in cleartext.  With cleartext headers, any SSH or TLS implementation that fails to do padding gets basically no traffic analysis protection at all, even if its communication partner does.  It’s indeed partly an “ecosystem problem” as Eben Moglen would say, and in the long term we need to try to fix that, but it’s hard.

With encrypted headers, however, *every* SSH or TLS conversation can get at least some (admittedly weak but still useful) protection against at least passive traffic analysis.  As many have said already, not all attackers are active MITM attackers; we need to care about passive attackers as well.  

And as I pointed out on the TLS list, TCP segments can be desynchronized from SSH or TLS records for many reasons and in a variety of points in the network, either intentionally or unintentionally: e.g., in the SSH or TLS implementation, in the TCP stack (by merging adjacent or time-proximate writes), or in middleboxes that resegment TCP streams.  Even if none of those network elements are *intentionally* trying to provide traffic analysis protection, even just the fact that they are sometimes unintentionally “messing up” the TCP segmentation boundaries makes things at least a bit harder and more noisy for passive attackers who only get to watch segments fly past and don’t get to mount dribble attacks and such.  And a single administrator can deploy a middlebox at the edge of a corporate or campus network to provide even better (still weak but better) traffic analysis protection for all SSH/TLS traffic crossing that middlebox, by deliberately delaying TCP segments just slightly and re-segmenting them on uniform MTU-size boundaries.

But only if SSH maintains encrypted headers, or if TLS adopts encrypted headers.

> encrypting the length hinders those countermeasures.

Your point that “serious" anti-traffic-analysis measures such as uniform padding are (currently) rarely implemented, which I believe, only makes the case stronger that we need to do everything we can to make traffic streams coming from that vast majority of non-traffic-analysis-protected implementations even just a bit more protected “at the outset” from even a subset of traffic analysis attackers.  Security is not a black-or-white, all-or-nothing thing where you might as well give up unless you can win the whole war in the first battle.

B