Subject: Re: AEAD in ssh

From: denis bider <[email-masked]>
Date: Thu, 25 Feb 2016 20:05:55 +0000

> You'd need to point to actual analysis (of the kind done in Peek-a-boo) to show that it works.

If I restrict myself to send the same amount of data, at regular intervals, independent of my packet queue; if I pick up packets from my queue if they are any, and send IGNORE messages otherwise; then this prevents keystroke analysis if done in 10 second bursts; and if I keep it up, it masks everything done on the connection.

A paper is not useful to show that this works. It evidently works. Yet, we cannot prove a negative. There are possible ways to get it wrong in practice.

If you can think of an attack, a paper can show if that particular attack is viable. But if you can't think of an attack, you can't write a paper to prove there isn't one.

> twenty years ago Tatu decided it was a good idea to use CRC32
> as an ICV, RC4 as a cipher, and encrypted lengths

By the same logic, Tatu also used C. Maybe we shouldn't use C because Tatu used that.

> So maybe we could do a profile for a special allegedly
> traffic-analysis resistant SSH, let's called it
> Data-oriented SSH or DoSSH,

You crack this joke, just after I pointed out that this costs 1 Mbps or less, whereas Netflix uses 3 - 5 Mbps. This is when Google Fiber is rolling out in the US, and we can expect 1 Gbps speeds to be normal in 15 years (if backward thinking people don't stop it).

You appear to be engaging in deliberate misunderstandings.

There's a repeated claim being made that there's an ongoing controversy about this topic. I'm now beginning to think that this would not be as much the case if we eliminated low-quality arguments.

---

From: denis bider <[email-masked]>
Date: Fri, 26 Feb 2016 11:15:07 +0000

Hey everyone -

pursuant to the recent discussion about what we can do about traffic analysis, I have written a draft for a mechanism to counter keystroke analysis, and generally provide more privacy for SSH terminal sessions. The first version of the draft is here:

https://tools.ietf.org/html/draft-ssh-fixed-bandwidth-00

This does not go as far as providing a complete blanket of the entire SSH session, since I assume this would currently entail unattractive bandwidth tradeoffs. However, it does seem to me that this will provide much better privacy for SSH terminal sessions, at a very acceptable cost.

The proposed mechanism is not defeated by unencrypted packet lengths. However, if packet lengths are encrypted, it will offer better privacy (fewer packets will stick out like sore thumbs because they can't be broken up, such as large channel requests); and when sending lots of data, it will be more efficient (less overhead due to larger packets allowed).

I have requested my colleagues that we implement this for a future version of our SSH Server and Client.

Comments welcome!

denis

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 29 Feb 2016 02:33:50 +0000

denis bider <[email-masked]> writes:

>If I restrict myself to send the same amount of data, at regular intervals,
>independent of my packet queue; if I pick up packets from my queue if they
>are any, and send IGNORE messages otherwise; then this prevents keystroke
>analysis if done in 10 second bursts; and if I keep it up, it masks
>everything done on the connection.

Well, you *think* it does, in the same way that people once thought traffic
padding would mask everything on the connection (I'm assuming they did, given
that it's the only anti-TA measure present in both TLS and SSH).  Show me
empirical data of it resisting attacks of the kind described in Peekaboo and
other papers...

>You crack this joke, just after I pointed out that this costs 1 Mbps or less,
>whereas Netflix uses 3 - 5 Mbps. This is when Google Fiber is rolling out in
>the US, and we can expect 1 Gbps speeds to be normal in 15 years (if backward
>thinking people don't stop it).

Yeah, and that's part of the way-too-common thinking that in the future we'll
all have infinite CPU, infinite RAM, and infinite bandwidth that leads to
people creating totally unworkable Rube-goldberg contraptions of crypto
protocols.  A few days ago I got to review two proposed ISO standards for IoT
in which a bunch of networking engineers tried to invent some sort of crypto
mechanism that makes WEP look like a model of good design, because both TLS
and SSH are far too bloated to work for them.  It's not their fault, they're
networking engineers and shouldn't be expected to have to do this, but the
crypto community just assumes infinite resources and goes from there.  I've
got users who don't want to move from SHA-1 to SHA-256 because of the extra
size introduced by the larger MACs, and you're telling me that we can all
dream of 1GBPs in the near future...

Peter.