Re: applying AES-GCM to secure shell: proposed "tweak"

[Nicolas Williams <Nicolas.Williams%Sun.COM@localhost>]

On Wed, Apr 15, 2009 at 10:56:41AM +0200, Niels Möller wrote:
> There seem to be two arguments for clear-text lengths:
> 
> 1. "I never liked the encrypted lengths, I think the TLS protocol
>    design is better".
> 
> 2. It causes additional complexity when implementing AEAD.
> 
> I don't find (1) convincing. I'd prefer not to make design changes of

There has been a security vulnerability that resulted from information
leaks that take place when the encrypted packet length is decrypted and
checked before the MAC is verified.  The leak was enormously compounded
by sending the decrypted packet length in a DISCONNECT packet, but also
by syslog()ing the decrypted packet length as well.

And it turns out that it's very difficult to hide the actual packet
length.  To do it properly you need to send IGNORE messages along with
all others, and you need to be very careful how the data is read so that
there can't be any TCP window adjustments that reflect the sizes of
read() calls.  i.e., you don't want to read() the packet length then
read() the rest, you want to read as much data as the lesser of max
packet size or the  amount of data that is in the receive buffers.  At
the very, very least we ought to document this.

> this type at this time, unless there's some really, really good
> reason. I'd not be surprised if there are some applications that rely
> on the ssh protocol feature that message lengths are encrypted, and
> are weakened if we change this. (I'd still appreciate to hear more
> details on what security problems others see with encrypted length
> fields, though).

I can't think of any such applications where random padding and random
IGNORE packets wouldn't suffice.  And keep in mind that all other
Internet protocols that encrypt traffic do not encrypt message lengths.

That isn't to say that I'm not concerned about a switch to cleartext
packet lengths.  There may be unexpected issues that arise from that.

> I find (2) extremely unconvincing, since the proposed solutions are
> additional levels of negotiation which adds a lot more complexity than
> it removes. I strongly dislike having several options for how the
> transport layer should work, I do *not* want to have that extra
> complexity at this level. One of the options will inevitably be less
> well-tested and more buggy than the other.

My proposal for negotiation is trivial.

Now that we think we know how to properly deal with encrypted packet
lengths one could argue that we should continue with that approach.  But
I would still prefer that we don't for the other reasons that we've
given, mostly that encrypted packet lengths with AEAD ciphers may
require changing APIs like, for example PKCS#11 (which, now has support
for GCM).

I've not looked at how PKCS#11 deals with AEAD, but I'm pretty sure that
it does not have any support for encrypted pacaket lengths.  And we want
to use PKCS#11 in SunSSH, and in fact, we do, though indirectly through
the OpenSSL PKCS#11 engine.  Forcing us to not be able to use PKCS#11
will severely impact future FIPS compliance projects.

> I'd like to propose the following guide-lines for using algorithms in
> the AEAD-class with ssh:
> 
> [...]
> 
> 2. The first block of each message is encrypted using a separately
>    keyed cipher. For AES-GCM, this could be AES in counter mode. For
>    proper authentication, the clear text for this block is included in
>    the "associated data" for AEAD, together with the implicit sequence
>    number, and any other context data that needs authentication. (A
>    slight elaboration of Damien Miller's idea).
> 
>    The choice for the cipher for the first block should of course be
>    chosen so that it reuses the same primitives as the AEAD-algorithm
>    that is used.

I'm OK with (2) as an option, as the default option.  It does add more
overhead over AEAD w/ cleartext packet lengths.

Nico
--