Re: SSH key algorithm updates

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 [email protected]

The way that RFC5647 was written seems to not have been widely adopted
although OpenSSH did implement [email protected] and
[email protected] 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