> On Apr 28, 2015, at 2:49 AM, Paul Wouters <p...@nohats.ca> wrote: > > On Tue, 28 Apr 2015, Yoav Nir wrote: > >> This is actually quite unfortunate text. Fields must be aligned to block >> size only for CBC. Aligning AES-GCM to 16 bytes and ChaCha20-Poly1305 to 64 >> bytes would be totally arbitrary, yet that is what the MUST requirement in >> the first bullet seems to be saying. I don’t even know what “proper >> alignment” means for a cipher such as this. If anything is proper alignment, >> then the value that fulfills the SHOULD requirement is zero (with no padding >> bytes). For section 3, I could add a text that echoes the second bullet: >> >> The sender SHOULD include no padding and set the Pad Length field to zero. >> The receiver MUST accept any length of padding. >> >> Sounds good? > > Not really? > > Choices like that make me nervous that an attacker can tweak the padding > option. Who knows what oracle that can become in the future. There MUST > only be one way to do things. So I would rather see: > > The sender MUST NOT include padding and set the Pad Length field to > zero. The receiver MUST reject a non-zero Pad Length field.
I’m OK with that as well, (though I would phrase it in the positive “The sender MUST include no padding and set …”), but that goes against RFC 7296. Specifically your second sentence turns a “MUST accept” into a “MUST reject”. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
