Hi. I've taken Damien writeup on Damien/Markus's chacha20-poly1305%openssh.com@localhost 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 chacha20-poly1305%openssh.com@localhost, 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
Attachment:
signature.asc
Description: PGP signature