Subject: Re: AEAD in ssh

From: denis bider <[email-masked]>
Date: Wed, 3 Feb 2016 00:30:10 +0000

I agree with Niels and Mark.

I have recently implemented AES-GCM, and I find the choice of unencrypted length fields dubious. It negates any means of obfuscating the lengths of some packets using SSH_MSG_IGNORE. 

The alternative - to encrypt packet lengths using a parallel construction - seems much preferable.

----- Original Message -----
From: Mark D. Baushke 
Sent: Tuesday, February 2, 2016 01:20
To: NielsMöller 
Cc: denis bider ; Stephen Farrell ; [email-masked] ; Watson Ladd ; Daniel Migault ; Curdle Chairs 
Subject: Re: AEAD in ssh 

Hi Niels & denis,

> 1. How to negotiate use of AEAD. 

Rather than "n/a" as the atom, why not "AEAD" or "aead" so we are clear
about the intent? That said, I am fine with ignoring the Mac if the
'Cipher' is an AEAD like the OpenSSH folks do if that is helpful.

Technically, aren't both AES-GCM and ChaCha20-Poly1305 considered to be
Authenticated Encryption with Associated Data (AEAD) rather than being
either a Mac or a Cipher directly?

> 3. If and how to encrypt the length field. 

+1 on encrypting the length field.

fwiw: I agree on the overall direction you have written.

-- Mark

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 3 Feb 2016 06:20:43 +0000

denis bider <[email-masked]> writes:

>I have recently implemented AES-GCM, and I find the choice of unencrypted
>length fields dubious. It negates any means of obfuscating the lengths of some
>packets using SSH_MSG_IGNORE.
>

See "Peek-a-Book, I Still See You: Why Efficient Traffic Analysis
Countermeasures Fail" by Dyer, Coult, Ristenpart and Shrimpton.  The
conclusion from the research: It's completely pointless, none of their attacks
even bother looking at the length field, so encrypting it is entirely
irrelevant.

Or, more importantly, it offers negative utility in that it makes processing
much harder and has led to exploitable vulnerabilities in the past.

Peter.

---

From: "Mark D. Baushke" <[email-masked]>
Date: Tue, 2 Feb 2016 22:39:50 -0800

Hi Peter,

Peter wrote:
> conclusion from the research: It's completely pointless, none of their
> attacks even bother looking at the length field, so encrypting it is
> entirely irrelevant.

Many thanks for the pointer to the document. At only fifteen pages, it
packs in a lot of useful information on Traffic Analysis (TA)
countermeasures for web sites into a single paper.

> Or, more importantly, it offers negative utility in that it makes
> processing much harder and has led to exploitable vulnerabilities in
> the past.

I do understand that processing is much harder and that exploitable
vunlerabilities are an issue.

I am not sure that the TA for web page traffic directly maps to the SSH
TA threats. That said, the paper does raise questions about how to
effeciently use such counermeasures and requires a bit more thinking
on my part.

	Thanks!
	-- Mark

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 3 Feb 2016 07:02:01 +0000

[email-masked] <[email-masked]> writes:

>That said, the paper does raise questions about how to effeciently use such
>counermeasures and requires a bit more thinking on my part.

It was a real eye-opener, it points out that the simplistic mechanism built
into both TLS and SSH for (attempting to) defeat traffic analysis pretty much
doesn't work.  There's been a bit of earlier work in this area (the work on
Bayesian classifiers, notably used by the Tor folks) but this is a 2nd-gen
study that looks at how to defeat countermeasures that that initial 1st-gen
work inspired.

I agree that there may be issues of applicability to SSH, but a bigger
question is the usual WYTM (what's your threat model), you need to figure out
what you're trying to defend against in order to evaluate your defences.  It'd
be nice to have some rigorous model like the random oracle model or standard
model in crypto.  The pad-the-packets approach doesn't really have any threat
model except that it seems like a good thing to do, what they've pointed out
is that it's ineffective against traffic classifiers.  Hopefully there'll be
more work on this in the future (although the previous papers were from 5-10
years ago)...

The tl;dr version, from a comment in my code:

  Padding in order to defeat traffic analysis is extremely problematic.  The
  simplistic approach of adding random padding provides little more than warm
  fuzzies since it falls almost trivially to statistical classifiers like
  Bayesian or support vector machines.  In fact almost any attempt to defeat
  traffic analysis with low overhead, including random padding, linear padding
  (padding to the nearest 128 bytes), exponential padding (padding to the
  nearest power of two), mice/elephant padding (padding short packets to 128
  bytes and long ones to the MTU), straight padding to the MTU, and padding by
  a random multiple of 8 or 16 bytes, doesn't work (see "Peek-a-Book, I Still
  See You: Why Efficient Traffic Analysis Countermeasures Fail" by Dyer,
  Coult, Ristenpart and Shrimpton).

  It's only when quite complex traffic morphing, sending fixed-length packets
  at fixed intervals and the like, is applied and reaches an overhead of 400%
  that things start getting tricky for an attacker, or at least an attacker
  using a straightforward Bayesian or SVM classifier.

  This doesn't leave much choice in the way of padding, since no matter what
  we do it won't be terribly effective.  The best option is to choose the
  variant with the lowest overhead and use that, since it has at least a small
  amount of effect.  This is linear padding, but we pad to 64 bytes instead of
  128 because we're typically used in embedded environments which both use
  shorter messages and often have bandwidth constraints.

Peter.