Subject: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-chacha20-poly1305-11: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 07 Jul 2015 16:15:01 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-ipsecme-chacha20-poly1305-11: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

intro: "gold standard" is being a bit too keen IMO, I'd say
toning the language down a bit would be better.

intro: 3DES may be the "only other widely supported" cipher
for IPsec, but that's not true more generally.

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..." 

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?

Appendices: thanks for those - I assume someone checked them
for you? (I didn't:-)

---

From: Yoav Nir <[email-masked]>
Date: Wed, 8 Jul 2015 08:36:56 +0300

Hi, Stephen.

See below.

> On Jul 8, 2015, at 2:15 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 

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.

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

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

> 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

Martin Willi (implementer of StrongSwan) did, and pointed out a mistake in a previous version.

Yoav

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 08 Jul 2015 08:18:46 +0100

Hiya,

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

>> 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:-)
> 

Thanks to you both!

Cheers,
S.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 8 Jul 2015 10:49:45 -0300

Sent from my iPhone

> On Jul 8, 2015, at 04:18, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 
> 
>> 
> I'm not sure if it's true for VPNs.

It is VERY true. There is only aes and 3des of you want to interop with non-opensource IKE or IPsec.

> Camellia is widely supported in

Not in IKE or IPsec.

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 08 Jul 2015 14:52:09 +0100

>> > browsers for example. So your text ought be fixed.

Then all that's needed is to qualify the "only" properly.
It's better to be accurate really I think.

S.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 9 Jul 2015 10:51:35 +0300

So, how about replacing the first two paragraphs?

OLD:
   The Advanced Encryption Standard (AES - [FIPS-197]) has become the
   gold standard in encryption.  Its efficient design, wide
   implementation, and hardware support allow for high performance in
   many areas, including IPsec VPNs.  On most modern platforms, AES is
   anywhere from 4x to 10x as fast as the previous most-used cipher,
   3-key Data Encryption Standard (3DES - [SP800-67]). 3DES also has a
   64-bit block, which means that the amount of data that can be
   encrypted before rekeying is required is not great.  These reasons
   make AES not only the best choice, but the only choice.

   The problem is that if future advances in cryptanalysis reveal a
   weakness in AES, VPN users will be in an unenviable position.  With
   the only other widely supported cipher being the much slower 3DES, it
   is not feasible to re-configure IPsec installations away from AES.
   [standby-cipher] describes this issue and the need for a standby
   cipher in greater detail.

NEW:
   The Advanced Encryption Standard (AES - [FIPS-197]) has become the
   go-to algorithm for encryption.  It is now the most commonly used 
   algorithm in many areas, including IPsec virtual private networks
   (VPN).  On most modern platforms AES is anywhere from 4x to 10x as 
   fast as the previous popular cipher, 3-key Data Encryption Standard 
   (3DES - [SP800-67]). 3DES also uses a 64-bit block, which means that 
   the amount of data that can be encrypted before rekeying is required 
   is limited. These reasons make AES not only the best choice, but the 
   only viable choice for IPsec.
   
   The problem is that if future advances in cryptanalysis reveal a
   weakness in AES, VPN users will be in an unenviable position.  With
   the only other widely supported cipher for IPsec implementations 
   being the much slower 3DES, it is not feasible to re-configure IPsec 
   installations away from AES. [standby-cipher] describes this issue 
   and the need for a standby cipher in greater detail.

Yoav

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Jul 2015 10:17:51 +0100

That change is really good thanks,
S