Re: ChaCha20-Poly1305 for SSH

[Stefan Bühler <ietf-ssh%stbuehler.de@localhost>]

Hi Damien,

On Tue, 3 May 2016 00:47:55 +1000 (AEST)
Damien Miller <djm%mindrot.org@localhost> wrote:

> On Wed, 20 Apr 2016, Stefan Bühler wrote:
> 
> > Hi,
> > 
> > some time ago I tried implementing ssh-chacha20-poly1305@openssh on
> > my own and was rather disappointed by the state of the
> > documentation in openssh (in the end the source code told me what I
> > needed to know).
> > 
> > Seeing draft-josefsson-ssh-chacha20-poly1305-openssh-00 I hoped
> > there would be some improvement... but well, it is just a copy of
> > the openssh file :)  
> 
> 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` !
- There is no reference to EtM-modes and how they handle padding.
- 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.

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

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

> > 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?

Which Chacha20 nonce size does it use? Does it actually use "invocation
counters" instead of the sequence counter? Does it use an IV as fixed
part of the nonce, or just zero bytes?

> > So I propose defining "chacha20-poly1305" as either the existing
> > "chacha20-poly1305%openssh.com@localhost" or as a slightly modified variant:
> > 
> > - using AEAD_CHACHA20_POLY1305 from RFC7539
> > - encrypt the packet length with otherwise discarded bytes from the
> >   first Chacha20 block, i.e. only a single Chacha20 instance  
> 
> I chose to use an independently-keyed instance of chacha20 for
> length field encryption to be completely sure there could be
> no possible decryption oracle between them. This was a deliberately
> conservative choice that was fortunately cheap since chacha20 is so
> fast.

I have no real preference here, I just found it could be a nice option
(I think Niels Möller presented it on the mailing list).

> > - pad the nonce to 12 bytes with zeroes on the left side, so one can
> >   simply reuse the original Poly1305 implementation with a 8-byte
> > nonce.
> > - openssh patch:
> >   https://github.com/rus-cert/openssh-portable/tree/feature-chacha20-poly1305  
> 
> I agree that if we are redoing the chacha20-poly1305 mode then it
> should match the parameter lengths used in other IETF protocols.

So the question is (again) whether we should do it or not.

> [...]
> 
> With regards to the future of the chacha20-poly1305, I'm hoping
> to interest a researcher in looking into length-hiding as a
> traffic-analysis countermeasure in the SSH protocol. The "Peek-a-boo"
> paper considers fingerprinting websites in the web attack model, which
> is very different to and in many ways more demanding than SSH's attack
> model. It would be good to have more definitive research that targets
> the SSH protocol and thread model passwords, keystroke timings, etc)
> and make a decision based on that.
> 
> With that out of the way, and if it yields a recommendation to
> pursue length-hiding then it's probably worth revisiting the exact
> construction. E.g. your proposal to use the remaining bytes from
> the first block, but I wasn't aware of [1] when I designed this mode.

I probably have to do some reading to even understand what this is
about :) But I don't think this should be considered only for
chacha20-poly1305 but for generic AEAD usage (if possible).

- Stefan