Subject: AEAD in SSH: Toss block alignment requirements

From: denis bider <[email-masked]>
Date: Sun, 28 Feb 2016 02:54:48 +0000

Hey everyone,

while implementing the "fixed-bandwidth" proposal, I realize we ought to get rid of block alignment requirements.

Using AES-CTR and hmac-sha2-256, it's straightforward to pad outgoing packets to some aligned size, e.g. 1024 bytes, using the following construction:

  SSH_MSG_CHANNEL_DATA ciphertext - 16-byte aligned
  SSH_MSG_CHANNEL_DATA mac - 32 bytes
  SSH_MSG_IGNORE ciphertext - 16-byte aligned
  SSH_MSG_IGNORE mac - 32 bytes

All lengths are 16-byte aligned, so we can always target an aligned total size.

If we try to do the same with hmac-sha1, there's a problem. But hmac-sha1 is deprecated, so maybe that's not an issue.

But with AEAD, we run into the issue again:

  SSH_MSG_CHANNEL_DATA length - 4 bytes
  SSH_MSG_CHANNEL_DATA ciphertext - 16-byte aligned
  SSH_MSG_CHANNEL_DATA tag - 16 bytes
  SSH_MSG_IGNORE length - 4 bytes
  SSH_MSG_IGNORE ciphertext - 16-byte aligned
  SSH_MSG_IGNORE tag - 16 bytes

The result isn't 16-byte aligned. This means we can't target a consistent total size, unless we ALWAYS add an SSH_MSG_IGNORE packet.

But there is no actual reason to have block size alignment with AEAD - or even CTR.

I propose the following:

- For inclusion in Niels's draft with AEAD guidelines, discourage or prohibit unneeded block alignment for packet receivers.

Optionally, we COULD also deprecate compulsory alignment for existing modes that don't need it, i.e. CTR. However, there is currently no recommended CTR + MAC combination where this would be a problem, since all plausible non-deprecated MACs are 16-byte aligned.

denis

---

From: [email-masked] (Niels Möller)
Date: Mon, 29 Feb 2016 14:37:14 +0100

denis bider <[email-masked]> writes:

> - For inclusion in Niels's draft with AEAD guidelines, discourage or
> prohibit unneeded block alignment for packet receivers.

In general, I'm thinking that padding is a useful complement to
SSH_MSG_IGNORE. In current use, one effect is that SSH_MSG_USERAUTH
"password" packets are close to fix size (in the absence of any other
traffic analysis countermeasures). If I count correctly, the payload of
a SSH_MSG_USERAUTH_REQUEST message requesting the "ssh-connection"
service and using password authentication is 40 bytes + the actual sizes
of username and password (and then it may be comprssed, I'm ignoring
that complication here, but I wouldn't expect it to change the size very
much).

With a 16 byte block size and minimum 4 bytes of padding, it doesn't fit
in three blocks, so it will be padded to 64 bytes + mac, with 19 bytes
of padding. So if len(username) + len(password) <= 15, we're getting a
cryptotext of 64 bytes, and if 16 <= len(username) + len(password) <=
31, we get 80 bytes. Which is a significant improvement over leaking the
exact length. 

(There are related issues for other message types, in particular
SSH_MSG_CHANNEL data, where pad-to-block-size could help hiding the
number of keystrokes. Assuming an implementation is able to collect
quickly typed characters into a single data packet, e.g., by setting
VMIN and VTIME on a unix terminal).

For AEAD, I am tempted to drop all MUST requirements on padding lengths
and leave it up to the implementation. However, I won't do that unless I
see some additional support here. And if we go that way, I think we have
to include some SHOULD rule which provides at least as good hiding of
userauth passwords as the original spec.

> Optionally, we COULD also deprecate compulsory alignment for existing
> modes that don't need it, i.e. CTR. 

I don't think it's a good idea to change the rules for non-AEAD ciphers.
We'll get incompatible versions for very little benefit.

And if you want to generate constant size TCP segments, you can do
arbitrary segment size regardless of padding rules, by sending TCP
segments which end with a partial SSH_MSG_IGNORE.

Regards,
/Niels

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