chacha20-poly1305 padding and length encoding The AEAD construction for chacha20-poly1305 described in the IETF proposal encodes message lengths into the text that is to be hashed. The newer proposal goes further and pads associated data and plaintext to multiples of 16 bytes.

Can anyone explain what the purpose of that is? The chacha20-poly1305 implementation found in OpenSSH doesn't do anything like that, and as far as I can see, neither does NaCl. Those are still considered secure so I wonder what's going on.
The reason for the padding (and re-positioning of the AAD length) in the later draft is to make implementations easier and faster - i.e. not for a security reason.

The rationale for this change was actually documented on the CFRG mailing list by Alyssa Rowan:


  Instead of the lengths directly following their ciphertexts:
  
  draft-agl-tls-chacha20poly1305-04:

  AAD | len_AAD | ciphertext | len_ciphertext

  
  this final version of the AEAD pads the Additional Authenticated Data
  (if any) and ciphertext to a 16-byte block boundary (using between
  0-15 zero bytes) and moves the lengths to the end:
  
  draft-nir-cfrg-chacha20-poly1305 (the final AEAD specified here):

  AAD | padding1 | ciphertext | padding2 | len_AAD | len_ciphertext

  
  which is more efficient to implement (block-aligned, and the recipient
  knows the lengths are at the end, instead of having to jump backwards
  to find len_AAD). Thanks to Niels Moeller for that idea.