Re: SSH key algorithm updates

["Mark D. Baushke" <mdb%juniper.net@localhost>]

Hi Jeff,

> > Or, is this better left to another RFC? Perhaps moving the Ed25519
> > algorithm created by
> > 
> >   https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-00 
> > 
> > into a MUST algorithm while deprecating "ssh-dss" for SSH?
> 
> 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.

Regading your table:

> enc   MAY         ???         4345  arcfour128
> enc   MAY         ???         4345  arcfour256

To the best of my understanding, these use CBC and I suggest

enc   MAY         SHOULD NOT  4345  arcfour128
enc   MAY         SHOULD NOT  4345  arcfour256

Regarding additional ciphers while the door is open.

How about RFC7539 ChaCha and Poly1305?

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

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?

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.

fwiw: I would have no problem with an ssh-rsa-sha2 pk.

	-- Mark