Re: ChaCha20-Poly1305 for SSH

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

On Tue, 3 May 2016, Stefan Bühler wrote:

> On Tue, 3 May 2016 00:47:55 +1000 (AEST)
> Damien Miller <djm%mindrot.org@localhost> wrote:
> 
> > It would be helpful if you said what in the documentation was
> > insufficient so we can improve it.
> 
> Fair enough:
> - "This forms two 256 bit keys (K_1 and K_2), used by two separate
>   instances of chacha20.", and then K_1 is used to encrypt the length.
>   But the keys are actually `K_2 || K_1` !

Thanks, I'll add a note to clarify.

> - There is no reference to EtM-modes and how they handle padding.

Why should there be?  EtM is completely separate.

> - By saying "no MAC is required" one might think that the MAC length is
>   zero and Poly1305 tag is somehow part of the packet content, and that
>   the length of it needs to be reflected in the length field.
>   But the MAC length is actually 16 bytes.

But the document doesn't say this. It says, in a section that describes
the KEX negotiation, "no MAC is required to be negotiated". IMO that's
quite clear from context.

Perhaps you're referring to the "no separate MAC is required" statement
in the same paragraph. This immediately follows a sentence that
describes the AEAD as including authentication. IMO the context is clear
here too.

The rest of the document discusses at length how the in-AEAD MAC is
derived and should be checked so nobody who read the whole thing
could (again IMO) come away with the impression that the protocol
includes no MAC or that it isn't included in the packet.

> I also feel the document is not structured very well, and a lot of
> things could be said more explicitly.

Such as? I'm happy to act on specific suggestions. Vague statements
of displeasure aren't really actionably though.

> But now I'm also curious: do you actually consider the document good
> enough to be published as RFC?

I'd consider it good enough to publish as an I-D, but I don't intend
to for the reasons I've already outlined.

> > > So I started to work on it, and also read some of the following
> > > discussion on ietf-ssh.
> > > 
> > > A large part of the discussion spun off discussing a whish list for
> > > a new binary packet protocol; changing the binary packet protocol
> > > probably requires rewriting core logic in many SSH implementations,
> > > so this should be done very carefully and not just for one cipher,
> > > and I somehow doubt it will happen soon.  
> > 
> > It's already happened: chacha20-poly1305 is supported by several
> > SSH implementations and uses a similar packet construction to
> > RFC5647 AES-GCM (with the exception of encryting the packet length).
> > There's also the -etm MACs in OpenSSH as Niels observes.
> 
> I can't find it on
> http://ssh-comparison.quendi.de/comparison/cipher.html, and I hope it
> isn't actually named "chacha20-poly1305" without being listed in the
> IANA registry. Can you give me any pointers?

http://ssh-comparison.quendi.de/comparison/cipher.html search for
chacha20-poly1305, scroll right.

-d