Hiya, On 08/07/15 06:36, Yoav Nir wrote: > Hi, Stephen. > > See below. > >> On Jul 8, 2015, at 2:15 AM, Stephen Farrell >> <stephen.farr...@cs.tcd.ie> 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.
I like your suggestion to Ben, with two tweaks: 1) s/has become the go-to/is by far the most commonly used/ 2) s/but the only choice// - "only" is factually incorrect, I could live with "only choice that achieves broad interoperability" > >> 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. The problem is the word "only" - that is simply not true in general. I'm not sure if it's true for VPNs. Camellia is widely supported in browsers for example. So your text ought be fixed. > >> 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, Yep, that's good. > >> 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. Ah fair enough, your text is correct so. > >> 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. Thanks to you both! Cheers, S. > > Yoav > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
