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

[Simon Tatham <anakin%pobox.com@localhost>]

Tim Polk  <tim.polk%nist.gov@localhost> wrote:
> Before moving forward with this protocol using either of the proposed
> solutions, we would appreciate feedback from this mailing list.
> Questions to consider:
> 
> (1) does the exposure of the ssh packet length have significant
> security implications for ssh itself?
> 
> (2) were applications that rely on ssh for security designed to take
> advantage of the encrypted packet length?
> 
> (3) does the change in padding length calculation (caused by excluding
> the packet_length from the ciphertext) impose a significant impediment
> to migrating existing implementations?

I was thinking about this when the recent vulnerability (CERT
VU#958563) was announced. I started thinking about what sort of a
binary packet protocol would have been intrinsically immune to
problems of that type, and came to similar conclusions: that the
problems with SSH-1's cleartext packet lengths arose from having
them correspond to the exact semantic size of an SSH message, and
it's not the case that cleartext lengths are _inherently_ harmful.

I came up with a design for a replacement BPP in two layers: the
outer layer divides the wire data stream into blocks each of which
is encrypted and MACed as a unit, and then the inner layer
conceptually glues the plaintext of all those blocks back together
and divides the resulting stream up into SSH messages by means of
separate markings within that stream. Then it's safe to send the
outer layer's block lengths in cleartext, (a) because they tell a
passive listener nothing that they couldn't have deduced from the
TCP segment boundaries anyway, and (b) an active attacker cannot
replace any block without having to forge a correct MAC for that
block. (Naturally the MAC also includes sequence numbers to prevent
block-rearrangement attacks.)

The division between semantic SSH messages in layer 2 is thus
decoupled from the division between blocks in layer 1, meaning that
you can transmit several messages in a block (saving space overall!)
or split one large message across several blocks if you like.

And finally, the MAC is applied to the ciphertext rather than the
plaintext, so you end up with a hard guarantee against leakage
attacks of the sort described in VU#958563: you cannot trick an
implementation into decrypting ciphertext of your choosing and
acting as an oracle, because nothing is even _shown_ to the
decryption code until it's passed its MAC, so first you would have
to forge a correct MAC for your chosen ciphertext.

I never quite got round to writing it up and posting it to this
list, mostly because I feared the general reaction would be that
nobody wanted to go right back to the start of the SSH protocol
design process at this stage :-) Would there be interest in seeing
it?
-- 
Simon Tatham         "A cynic is a person who smells flowers and
<anakin%pobox.com@localhost>    immediately looks around for a coffin."