Subject: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-00.txt

From: [email-masked]
Date: Mon, 30 Mar 2015 06:32:37 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF.

        Title           : ChaCha20, Poly1305 and their use in IPsec
        Author          : Yoav Nir
	Filename        : draft-ietf-ipsecme-chacha20-poly1305-00.txt
	Pages           : 6
	Date            : 2015-03-29

Abstract:
   This document describes the use of the ChaCha20 stream cipher along
   with the Poly1305 authenticator, combined into an AEAD algorithm for
   IPsec.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Yoav Nir <[email-masked]>
Date: Mon, 30 Mar 2015 17:39:48 +0300

Hi,

There is two questions I would like guidance from the group about.

First is the nonce/IV question: In the current draft, there is a 64-bit IV with guidance not to repeat them (so use a counter or LFSR). The function itself accepts a 96-bit input nonce, so the nonce is constructed from the 64-bit IV and 32 zero bits. The reason for doing this is so the algorithm could be used in a multi-sender case such as GDOI, where the 32-bit zero can be replaced by a sender ID. Alternatively, we could generate a 32-bit salt value from the key material, but I don’t see a reason why we’d want that. Another thing we could do is what some people are advocating for TLS: Since a counter is a fine IV (no need for secrecy), we don’t need a 64-bit IV that has the exact same value as the replay counter. We might as well save 8 bytes per packet and just feed the replay counter to the function.  The argument against this is that some crypto modules may have the API set up in such a way that the IVs are generated within the module and could be something other than a counter (like an LFSR). The proposal will break such APIs.

Second issue is about UI advice. Some implementations (yes, mine is included) allow the user to configure encryption algorithm, MAC algorithm, and D-H group. There is no setting for PRF since such UIs date back to IKEv1. The PRF is usually just taken from the setting for MAC algorithm. This works fine as long as all supported MAC algorithms are HMAC, XCBC, and CMAC. AES-GCM would have the same issue, but RFC 5282 makes no mention of this issue. I’m wondering if we should recommend to pair this algorithm in IKE with PRF_HMAC_SHA2_256.

Thanks

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Mon, 30 Mar 2015 18:15:07 +0300

Arrgh. Please don’t reply-all to my previous message, because it was mistakenly directed to I-D announce…

> On Mar 30, 2015, at 5:39 PM, Yoav Nir <[email-masked]> wrote:
> 
> Hi,
>

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Mon, 30 Mar 2015 17:42:27 +0000

-----Original Message-----
From: IPsec [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Monday, March 30, 2015 10:40 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00

> First is the nonce/IV question: In the current draft, there is a 64-bit IV with guidance not to repeat them (so use a counter or LFSR). The function itself accepts a 96-bit input nonce, so the nonce is constructed from the 64-bit IV and 32 zero bits. The reason for doing this is so the algorithm could be used in a multi-sender case such as GDOI, where the 32-bit zero can be replaced by a sender ID. 

This idea about the multi-sender case works only if the there's a sender id somewhere in the encrypted packet.

> Alternatively, we could generate a 32-bit salt value from the key material, but I don’t see a reason why we’d want that.

Here's the reason that we do use the 32-bit salt value for GCM - to prevent batching attacks.

Consider the case that an attacker is able to collect packets from a billion (2^30) sessions; each such session contains a packet with the same IV (say, IV=0), and contains a packet with the same known plaintext (or, at least, plaintext that satisfies the same known linear equations).  Then, what an attacker can do is check a key to see if any of the IV=0 packets used that key, in constant time.  The reduces the effort for an attacker to find the n bit key for some session from 2^n to 2^{n-30}.  What the salt does is multiply the effort involved in this specific attack by a factor of 2^32 (because the attacker needs to guess the key and the salt); that way, the attacker needs to collect 4 billion sessions before this attack starts to have any advantage over a simpler attack that just attacks a single packet (which the salt doesn’t protect against).

Now, of course, chacha20 has 256 bit keys; hence even if we decided not to apply the same protection, someone with a collection of a billion sessions might be able to use this to reduce the effort to 2^226.

I'll let you decide whether this is a compelling argument or not...

---

From: Yoav Nir <[email-masked]>
Date: Tue, 31 Mar 2015 12:15:17 +0300

One more thing.

I would like to request early code point assignment for ESP_ChaCha20-Poly1305.

I know that it is the goal of the chairs to bring this to LC sooner rather than later, but I would like to get started on implementation sooner rather than later, and the IETF process takes three months at best, and six months in the more common case.

Thanks

Yoav

> Begin forwarded message:
> 
> From: [email-masked]
> To: <[email-masked]>
> Date: March 30, 2015 at 4:32:37 PM GMT+3
> Cc: [email-masked]
> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-00.txt
> 
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 31 Mar 2015 13:49:56 +0300

Yoav Nir writes:
> First is the nonce/IV question: In the current draft, there is a
> 64-bit IV with guidance not to repeat them (so use a counter or
> LFSR). The function itself accepts a 96-bit input nonce, so the
> nonce is constructed from the 64-bit IV and 32 zero bits. The reason
> for doing this is so the algorithm could be used in a multi-sender
> case such as GDOI, where the 32-bit zero can be replaced by a sender
> ID. Alternatively, we could generate a 32-bit salt value from the
> key material, but I don’t see a reason why we’d want that.

Reserving that 32-bits as sender-ID is fine...

> Another thing we could do is what some people are advocating for
> TLS: Since a counter is a fine IV (no need for secrecy), we don’t
> need a 64-bit IV that has the exact same value as the replay
> counter. We might as well save 8 bytes per packet and just feed the
> replay counter to the function. The argument against this is that
> some crypto modules may have the API set up in such a way that the
> IVs are generated within the module and could be something other
> than a counter (like an LFSR). The proposal will break such APIs.

As Kent explained in the meeting, if you move the IV generation out
from the crypto operation, then that also moves the FIPS boundary,
i.e. if the uniqueness of the IV generation (counter) is inside the
IPsec module, not in the ChaCha20 module, then you need to FIPS
certify whole thing.

On the other hand with IPsec I think you mostly need to FIPS certify
quite a lot of stuff anyways...

On the other hand, I think it would be possible to do things other way
around, i.e. make cipher to internally generate IV, but define that IV
MUST be running counter starting from 0, and use that counter as
sequence number in the ESP and compress sequence number out from the
packet. I.e. we would still have IV (coming form inside the crypto
boundary), but we compress the sequence number away, as it would
always be the same as IV...

Currently we cannot do that, as we do not define how the IVs are
generated, thus the IPsec part cannot know for sure that IVs are
generated in such way.

On the other hand if we define this cipher in such way that IV MUST be
generated such way, then we could make sequence number compression
option in the future, which would compress sequence number away from
the actual packet... I.e. gain the same effect, but not compressing
the IV, but compressing the sequence number...

This would save 32-bits from the packet, as only 32-bits of the
sequence number is transmitted, not the full 64-bits, but that would
still be something, and if even more IV compression is needed, there
would be ways to only transmit smaller part of the IV and then
reconstruct it before decryption and verification.

These compression extensions could happen after ESP encryption and
before ESP decryption, so the actual ESP packets seen by the engine
would be exactly same, only difference would be that they would need
to maintain strict requirement that SEQ matches IV...

> Second issue is about UI advice. Some implementations (yes, mine is
> included) allow the user to configure encryption algorithm, MAC
> algorithm, and D-H group. There is no setting for PRF since such UIs
> date back to IKEv1. The PRF is usually just taken from the setting
> for MAC algorithm. This works fine as long as all supported MAC
> algorithms are HMAC, XCBC, and CMAC. AES-GCM would have the same
> issue, but RFC 5282 makes no mention of this issue. I’m wondering if
> we should recommend to pair this algorithm in IKE with
> PRF_HMAC_SHA2_256. 

There is no need in IKEv2 to tie the PRF to other algorithms, so I see
no reason to do so in this draft.

On the other hand the other draft making the UI suite for this will of
course need to select suitable PRF, but that draft might want to wait
for new EC curves, so we could have complete DJB suite...

Btw, in the draft introduction you have text which says:

   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 to use 3DES.
   [standby-cipher] describes this issue and the need for a standby
   cipher in greater detail.

I do not think the problem with 3DES is the speed, I think the bigger
problem is the way too short block length of it. As RFC7321 says:

   The Triple Data Encryption Standard (TDES) is obsolete because of its
   small block size; as with all 64-bit block ciphers, it SHOULD NOT be
   used to encrypt more than one gigabyte of data with a single key
   [M13].  Its key size is smaller than that of the Advanced Encryption
   Standard (AES), while at the same time its performance and efficiency
   are worse.  Thus, its use in new implementations is discouraged.

With gigabit links that would mean rekeying every ten seconds or so... 
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Tue, 31 Mar 2015 13:57:54 +0300

Seeing as none of the transform names begins with “ESP_” and that we’re specifying the algorithm for IKE as well as ESP, I’ve changed the identifier to ENCR_ChaCha20_Poly1305.

Yoav

> On Mar 31, 2015, at 12:15 PM, Yoav Nir <[email-masked]> wrote:
> 
> One more thing.
> 
>> From: [email-masked] <mailto:[email-masked]>
>> To: <[email-masked] <mailto:[email-masked]>>
>> Cc: [email-masked] <mailto:[email-masked]>
>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/ <https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/>
>>

---

From: Paul Wouters <[email-masked]>
Date: Tue, 31 Mar 2015 10:03:16 -0400 (EDT)

On Tue, 31 Mar 2015, Yoav Nir wrote:

> Seeing as none of the transform names begins with “ESP_” and that we’re specifying the algorithm for IKE as well as ESP, I’ve changed
> the identifier to ENCR_ChaCha20_Poly1305.
> Yoav

Can we make it ENCR_CHACHA20_POLY1305 ?

Currently IANA mostly has no CamelCase and it is kind of a C habbit to
have defines in CAPS :)

Paul

---

From: Yoav Nir <[email-masked]>
Date: Tue, 31 Mar 2015 17:16:24 +0300

> On Mar 31, 2015, at 5:03 PM, Paul Wouters <[email-masked]> wrote:
> 

I guess, although some of the names don’t quite work as identifiers: "AES-GCM with a 8 octet ICV” or "ENCR-AES-CCM_12”, which is surprisingly different in terms of dashes vs underscores than “ENCR_AES-CCM_8”.

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Tue, 31 Mar 2015 10:40:56 -0400 (EDT)

> I guess, although some of the names don’t quite work as identifiers: "AES-GCM with a 8 octet ICV” or "ENCR-AES-CCM_12”, which is surprisingly different in terms of dashes vs underscores than “ENCR_…

And I've poked both PaulH and Tero to never ever add more names with a
"-" in it because that has to be replaced by "_" in C.

My apologies I wasn't very active at the time this happened :)

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 31 Mar 2015 19:51:05 +0300

Paul Wouters writes:
> > I guess, although some of the names don’t quite work as
> > identifiers: "AES-GCM with a 8 octet ICV” or "ENCR-AES-CCM_12”,
> > which is surprisingly different in terms of dashes vs underscores
> > than “ENCR_AES-CCM_8”. 

How has that happened. Hmmm... looking at the archives that was there
from the beginning. And those assignments which were done at the same
time as RFC4306 was published (i.e. RFC4309 and RFC4106) never went
through the IANA Expert review, hey were simply added to registry
without asking from anybody...

This was the time when we had some communications issues between IANA
and experts... 

> "-" in it because that has to be replaced by "_" in C.

As an IANA expert, I try maintain the registry so it stays consistent,
but unfortunately when the registry already had those ENCR_AES-CCM_8,
ENCR-AES-CCM_* and AES-GCM with * octet ICV values already in before
expert was every consulted, those are still there.

The AEs-GCM values have annoyed me, as they are only ones without
ENCR_* prefix. I have never really noticed that ENCR-AES-CCM had - not
_ in between ENCR-AES, the one between AES-CCM I have noticed, but
haven't bothered to fix those yet.

On the other hand all of these are just strings so they do not affect
protocol. 

> My apologies I wasn't very active at the time this happened :)

If people feel it would be better to fix those, we can do that, i.e.
change:

14 	ENCR_AES-CCM_8
15 	ENCR-AES-CCM_12
16 	ENCR-AES-CCM_16
18 	AES-GCM with a 8 octet ICV
19 	AES-GCM with a 12 octet ICV
20 	AES-GCM with a 16 octet ICV
25 	ENCR_CAMELLIA_CCM with an 8-octet ICV
26 	ENCR_CAMELLIA_CCM with a 12-octet ICV
27 	ENCR_CAMELLIA_CCM with a 16-octet ICV

To:

14 	ENCR_AES_CCM_8
15 	ENCR_AES_CCM_12
16 	ENCR_AES_CCM_16
18 	ENCR_AES_GCM with a 8 octet ICV
19 	ENCR_AES_GCM with a 12 octet ICV
20 	ENCR_AES_GCM with a 16 octet ICV
25 	ENCR_CAMELLIA_CCM with an 8-octet ICV
26 	ENCR_CAMELLIA_CCM with a 12-octet ICV
27 	ENCR_CAMELLIA_CCM with a 16-octet ICV

Or even change the "n-octet" term to be consistent:

14 	ENCR_AES_CCM_8
15 	ENCR_AES_CCM_12
16 	ENCR_AES_CCM_16
18 	ENCR_AES_GCM with a 8-octet ICV
19 	ENCR_AES_GCM with a 12-octet ICV
20 	ENCR_AES_GCM with a 16-octet ICV
25 	ENCR_CAMELLIA_CCM with an 8-octet ICV
26 	ENCR_CAMELLIA_CCM with a 12-octet ICV
27 	ENCR_CAMELLIA_CCM with a 16-octet ICV

Or even go wild and change them:

14 	ENCR_AES_CCM_8
15 	ENCR_AES_CCM_12
16 	ENCR_AES_CCM_16
18 	ENCR_AES_GCM_8
19 	ENCR_AES_GCM 12
20 	ENCR_AES_GCM_16
25 	ENCR_CAMELLIA_CCM_8
26 	ENCR_CAMELLIA_CCM_12
27 	ENCR_CAMELLIA_CCM_16
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 31 Mar 2015 13:24:01 -0400 (EDT)

> This was the time when we had some communications issues between IANA

Is that when Camellia went through as well? :P with different numbers
for IKEv1 and IKEv2 :P  [insert implementer anger :)]

> On the other hand all of these are just strings so they do not affect

Agreed, but it's nice to be able to grep other people's source code :P

> Or even go wild and change them:

It would be great if we could do that! But if we can change these, why
can we not also change "-" into "_" ?

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 31 Mar 2015 22:19:17 +0300

> for IKEv1 and IKEv2 :P  [insert implementer anger :)]

The Camellia RFC 4312 only allocated numbers for IKEv1 not for IKEv2.
The IKEv2 then got few allocations (ENCR_NULL_AUTH_AES_GMAC, and one
for XTS-AES) between and the number 22 was not available anymore when
the RFC to allocate CAMELLIA for IKEv2 came through, or to be more
accurate, when the authors of RFC4312 wanted to do IANA allocation for
CAMELLIA_CBC for IKEv2 too. I said as if it is going to be different
number, better write new RFC, and while they did that they also added
CTR, and CCM modes in it...

Anyways there is no real reason to keep the IKEv1 and IKEv2. The
reason we had different registries was that they are two different
protocols, and for example in the IKEv2 the Encryption Algorithms
registry was used by both IKEv2 SA and ESP, as in IKEv1 there were
separate registries for them. Also IKEv1 is used with ESPv2 and cannot
really support combine mode ciphers, but that didn't stop people
defining them in IKEv1 registries too.

So it was clear that they would get out of sync at one point, so each
implementation had to solve that somehow anyway. The initial
registries were compatible to make supporting boht IKEv1 and IKEv2,
but after that changes happen.

> can we not also change "-" into "_" ?

I did that, but seem to have missed one " " in ENCR_AES_GCM 12"
-- 
[email-masked]