Re: AEAD in ssh

[Damien Miller <djm%mindrot.org@localhost>]

On Mon, 1 Feb 2016, Niels Möller wrote:

> denis bider <ietf-ssh3%denisbider.com@localhost> writes:
> 
> > With regard to AEAD:
> >
> > I think we should just make the following simple and clear statement:
> >
> > MAC algorithms are secondary to encryption algorithms, and are
> > evaluated only if the encryption algorithm is not AEAD. If an AEAD
> > encryption algorithm is negotiated, the outcome of MAC negotiation is
> > irrelevant and must be ignored. If no mutual MAC algorithms are
> > available, this causes key exchange to fail if, and only if, the
> > negotiated encryption algorithm is not AEAD.
> 
> That's only one part of it. I think the following points need clear
> specification:
> 
> 1. How to negotiate use of AEAD. 
> 
>    The above would work, I think. 
> 
>    Or one could specify a "n/a" mac name, which is a bit like "none",
>    except that negotiation fails if it's the output of the mac
>    negotiation and the negotiated cipher isn't an aead mechanism. Maybe
>    unnecessary, but it could also serve the second purpose as signalling
>    support for aead, in case the negotiation rules need tweaking (see
>    also next point). If defined, it should be mandatory (i.e., if the
>    agreed cipher is aead, but "n/a" mac isn't offered, connection should
>    fail).

I prefer Denis' forumation (which matches what we in OpenSSH for AEAD)
ciphers, it's simpler, harder to get wrong and less likely to fail at
runtime through user misconfiguration.

The only cost is that the KEX code needs to be able to easily
tell whether an algorithm is an AEAD before it starts working on
the MAC. The change to OpenSSH's KEX code to support AEAD ciphers
was trivial: https://anongit.mindrot.org/openssh.git/diff/kex.c?id=1d75abfe

> 2. How it interacts with first_kex_packet_follows. 
> 
>    Roughly, if everything is "guessed" correctly except the mac
>    algorithm (e.g, if the mac name-list is empty so mac negotiation
>    fails), and the agreed cipher is aead, the guess ought to
>    nevertheless be considered successful. The details must be made
>    crystal clear. 
> 
>    (And I'm open to tweaking the rules in other ways too, if new rules are
>    reliably signalled via some extension or by the "n/a" atom; it's
>    unclear to me if the first_kex_packet_follows logic really needs to
>    depend on anything else but the agreed key exchange mechanism and
>    maybe host_key_algorithm (I think I can argue that it's independent
>    of host_key_algorithm: Every reasonable keyexchange algorithm needs
>    input from the client, and the key exchange signature must depend on
>    that data. Hence the first kex packet should be independent of the
>    signature)).

I don't think the first_kex_packet_follows rules need adjustment if
mac negotiation is simply ignored for ciphers that are AEAD.

> 3. If and how to encrypt the length field. 
> 
>    My strong opinion is that it ought to be encrypted. A spec for AEAD
>    in ssh should either specify fully how to do that, or give clear
>    guidelines in case some details must be left to the specification of
>    each AEAD mechanism. Roughly, one should use an independent cipher
>    instance (distinct key or disjoint nonce sequence or distinct ctr
>    value) to encrypt the length in a ctr-like mode.

IMO this is completely up to the AEAD itself. OpenSSH supports an AEAD that
does (chacha20/poly1305) and AES-GCM that doesn't. I'm not convinced that
encrypting packet lengths wouldn't contribute to an effective traffic
analysis mitigation scheme -- the "peek-a-boo" paper clearly shows they
are not sufficient, but that's not the same as saying that it isn't
necessary, or can't help.

OTOH I'll freely admit that the point is moot in the absense of a
threat model and until implementations actually implement serious
traffic analysis mitigations.

I don't accept Peter's argument that encrypting length fields
is a net negative for security. An independently keyed cipher for
length encryption is never going to act as an oracle in the same
way as the CBC+bad MAC order mess was.

> 4. What the "block size" used for padding purposes (RFC 4253, Sec. 6,
>    "Binary Packet Protocol") should be. 
> 
>    AEAD in the abstract doesn't expose any block size, so I'd be
>    inclined to say that we should always use 8, the ssh minimum. One
>    could tie it to the underlying block cipher if there is one, but it
>    makes little sense to me, given that it's the length *including* the
>    length field which must be a multiple of the "block size". And with
>    AEAD, the length field has to be separately encrypted, so by the
>    current rules, we're always going to be unaligned anyway.

I don't think it makes sense to try to define this for AEAD modes in
abstract, it's a concrete property of the individual algorithms.

> The existing RFC 5647 on aes-gcm is unclear on (1) and (2) (and
> apparently not implemented that way in openssh).

RFC5647 is quite clear on negotiation, but it doesn't follow either
scheme mentioned above (with are both IMO much more reasonable),
instead it requires (section 5.1) that "AEAD_AES_*_GCM" be selected
for both cipher and MAC. I think this offers even more opportunities
for runtime failure and misconfiguration.

> In short, to write a good specification will require some non-trivial
> amount of work. And I think it's pretty important work. Do you agree?
> Are there any objections to the above direction? (I already know some
> dislike encrypted lengths). What are the chances to reach rough
> consensus?

IMO the best approach to the problem is to define the right way to
negotiate AEAD algorithms in KEX, but specify the AEADs individually.

If I had a time machine then I'd go back to 2000, buy a bunch of
stocks and then argue that SSH2 should only negotiate complete AEADs
rather than separate ciphers and MACs. I'd almost certainly be
dismissed as a crank, but at least I'd be rich when I got back.

-d