Re: AEAD in SSH: Toss block alignment requirements

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

denis bider <ietf-ssh3%denisbider.com@localhost> 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.