Hi, Stephen. See below.
> On Jul 8, 2015, at 2:15 AM, Stephen Farrell <[email protected]> wrote: > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > intro: "gold standard" is being a bit too keen IMO, I'd say > toning the language down a bit would be better. AES is what I get when I’m using IPsec, TLS (at least in browsers and SMTP) and SSH with normal tools. It’s what disk encryption schemes use and what S/Mime uses. Even the DICE profile names AES as the MTI algorithm. Same for the current TLS 1.3 draft and HTTP/2 RFC. When Intel was looking to add a cryptographic algorithm to the general-purpose CPUs, they chose AES. IBM did the same with mainframe CPUs. Any paper describing a new algorithm compares the new algorithms to AES. Even here at the IETF we tend to call anything else “vanity crypto”. I think “gold standard” is appropriate. I guess I could rephrase it as “has become the go-to algorithm for encryption”, although that might be too American an idiom. > intro: 3DES may be the "only other widely supported" cipher > for IPsec, but that's not true more generally. Well, this is a document about IPsec. It’s also true for TLS and SSH. There’s also the occasional Blowfish and Camelia, but 3DES is more common than any of them. There is RC4 and it’s fast, but (1) you can’t use that in IPsec, and (2) you don’t want to use that in TLS and SSH anyway. > section 2 says: "As the ChaCha20 block function is not applied > directly to the plaintext, no padding should be necessary." > That "should" could be confusing as written if a reader thinks > it means their code doesn't have to do padding. It might be > better to e.g. say something like "In theory no padding is > needed for this cipher, however, in keeping with…" I take the point, but I don’t like using “in theory”. How about: As the ChaCha20 block function is not applied directly to the plaintext, the algorithm does not require any padding. However, > section 3: Is "SHOULD inlude no padding" really right? I'd > have thought a MAY was better there. "MUST accept any length" > is also a bit odd - what if I (try:-) add loads of padding? This pretty much follows the text in RFC 7296: o Pad Length is the length of the Padding field. The sender SHOULD set the Pad Length to the minimum value that makes the combination of the payloads, the Padding, and the Pad Length a multiple of the block size, but the recipient MUST accept any length that results in proper alignment. This field is encrypted with the negotiated cipher. Since there is no proper alignment requirements for this algorithm, I take that to mean “no padding” but “MUST accept any length”. It’s true that with a single-octet byte length you can’t insert more than 255 octets of padding, but I don’t thin this has to be spelled out. > Appendices: thanks for those - I assume someone checked them > for you? (I didn't:-) Martin Willi (implementer of StrongSwan) did, and pointed out a mistake in a previous version. Yoav _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
