Re: SSH key algorithm updates

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

On Sat, 31 Oct 2015, Mark D. Baushke wrote:

> > That's an unfinished, -00 version internet draft from CFRG.  It's
> > probably too soon to use it as the basis for an SSH public key algorithm
> > at all, let alone make such an algorithm mandatory to implement.  Once
> > the document is ready, we can start with OPTIONAL, and consider
> > upgrading when the algorithm has proven itself and is reasonably widely
> > implemented in SSH.
> 
> Hmmm.... OpenSSH has implemented an ssh-ed25519 and B. Harris has
> written:
> 
>   https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-02
> 
> I am not sure how closely the IRTF Ed25519 an ssh-ed25519
> implementations match, but I suspect it may be relevant to discuss
> both drafts and the SSH protocol sooner rather than later.

AFAIK ssh-ed25519 is compatible with CFRG consensus on new
signature schemes, but it's not yet become an I-D.

> OpenSSH has implemented chacha20-poly1305%openssh.com@localhost

Since we did that there has been an RFC on using this combination
https://tools.ietf.org/html/rfc7539 which is incompatible with ours.

The OpenSSH one, among other less-notable differences, maintains a
second chacha20 instance to encrypt packet lengths.

AFAIK a couple of other implementation support the openssh version.

> The way that RFC5647 was written seems to not have been widely adopted
> although OpenSSH did implement aes128-gcm%openssh.com@localhost and
> aes256-gcm%openssh.com@localhost which are very similar. It might be nice to
> actually come up with a 'standards' track document dealing with AEAD
> ciphers and SSH and see if there is a better way to negotiate it within
> the existing framework of SSH's separation of MAC and Cipher. For
> example, maybe MAC=AEAD and Cipher=aes-gcm,chacha20-poly1305 would make
> more sense in the negotiation?

The situation wrt aes-gcm is frustrating. A draft was posted by a NSA
employee here a few years ago, and there was quite a bit of feedback
that the negotiation method that it proposed effectively broke
negotiation of non-AEAD ciphers. The NSA/IETF standardised it anyway.

The only difference between the NSA/IETF RFC and the openssh
implementation is that we fixed the negotiation in kex.

> It would be useful to see what other protocols various SSH implementers
> have been adding and see if there is a desire to move any of them into a
> recommended or optional standard.
> 
> There is also the possibility of a encrypt-then-mac kinds of MAC choices
> to try to avoid attacks against block ciphers which are either
> mac-then-encrypt or AEAD.

OpenSSH has had encrypt-then-MAC modes as the default for some time. 

One other thing worth mentioning is the curve25519-sha256%libssh.org@localhost
key exchange method. It's supported by a few implementations and is
AFAIK compatible with the CFRG curves draft.

We'll probably do curve448 KEX and public key schemes in the near future,
with the NSA's recent de-recommendation of 256 bit EC.

With regard to recommended options, my take is something like:

kex: curve25519-sha256, with ecdh-sha2-nistp* as a second choice
pubkey: ed25519, with ecdsa-sha2-nistp* as a second choice
cipher: chacha20-poly1305, with aes*-gcm%openssh.com@localhost as second choice

(second choices for people who suffer under the yoke of FIPS compliance)

-d