ChaCha20-Poly1305 for SSH

Simon Josefsson <[email protected]> Thu, 26 Nov 2015 11:08:59 +0100
Newsgroups	gmane.ietf.secsh
Message-ID	<[email protected]>
Hi.  I've taken Damien writeup on Damien/Markus's
[email protected] and put that into an IETF draft:

https://tools.ietf.org/html/draft-josefsson-ssh-chacha20-poly1305-openssh-00

There have been some offlist conversation about how to move forward with
this in the IETF.  The challenge is that the construct differs from the
ChaCha20-Poly1305 construct used in RFC 7539.

To have something to start IETF discussions, I thought it would be
useful to have the OpenSSH-specific construct described in a draft.

We could turn this into an IETF blessed approach by stripping
"@openssh.com" and register that with IANA, similar to what is done for
curve25519.

We could also describe a new SSH encryption algorithm that is based on
the RFC 7539 construct.  Still using ChaCha20-Poly1305, of course, but
it would work differently.

As far as I understand, the critical technical difference between these
approaches is whether encrypting the length field is useful or not.  I'm
told that encryption the field is of limited use because traffic
analysis would see the packet lengths anyway.

Regardless of whether it is useful to do this, I believe it would be a
bad idea to push something in IETF that SSH implementers aren't
interested in implementing.  So if we do something other than stripping
@openssh.com I believe we will need to build consensus for doing that
among implementers first.

For consistency and simplicity of algorithm description, I do want to
see a RFC 7539 based approach explored though, and we may end up writing
a different draft on that.

If you are an SSH implementer that supports
[email protected], are you interested in implementing
support for a more streamlined variant that would lack encryption of the
length field?

Does anyone see a strong need for encrypting the length field?

/Simon
signature.asc (application/pgp-signature, 472 B)