Subject: Re: [IPsec] Early code point assignment (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-00.txt)

From: Yoav Nir <[email-masked]>
Date: Wed, 1 Apr 2015 14:26:02 +0300

OK, so this thread kind of got side-tracked about the name of the algorithm.  I think ENCR_CHACHA20_POLY1305 works for everybody.

What about early code point assignment?

Thanks

Yoav

> On Mar 31, 2015, at 12:15 PM, Yoav Nir <[email-masked]> wrote:
> 
> 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

---

From: Paul Wouters <[email-masked]>
Date: Wed, 1 Apr 2015 09:40:28 -0400 (EDT)

> What about early code point assignment?

Just to confirm, yes please. As I said before, let's not have another
twofish/serpent private use number in common use.

Paul

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 01 Apr 2015 09:24:37 -0700

Not while the latest revision still has two TBDs, while we're still 
debating two interop-critical issues (padding, salt) and another major 
security issue (IV).

I don't want private use numbers any more than PaulW, but I also don't 
want errata like we had for TLS EtM.

We can iron out these issues within a week or two and then I'd be all in 
favor of a code point assignment.

Thanks,
	Yaron

On 04/01/2015 04:26 AM, Yoav Nir wrote:
> OK, so this thread kind of got side-tracked about the name of the
> algorithm.  I think ENCR_CHACHA20_POLY1305 works for everybody.
>
>> On Mar 31, 2015, at 12:15 PM, Yoav Nir <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> One more thing.
>>
>> 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
>
>
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 2 Apr 2015 02:44:15 +0300

> twofish/serpent private use number in common use.

While we are still discussing whether having 32-bit or 64-bit length
fields in the mode, I think it is too early to allocate number for
chacha20 (see last comments on the list).

At least I want to make sure the draft is stable enough so that there
will NOT be any bits on the wire changes after we allocate the real
number. Before that it is better to use private numbers.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Thu, 2 Apr 2015 13:41:14 +0300

> On Mar 31, 2015, at 1:49 PM, Tero Kivinen <[email-masked]> wrote:
> 
> 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…

Such a compression extension would work fine for both ChaCha20-Poly1305 and AES-GCM at least. Probably the other currently-defined AEAD mode. OK, for now I’ll leave the TBD in, but I won’t change the text.

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

The Create Child SA exchange can be efficiently run every ten seconds or so, and most VPN tunnels are not that saturated. So I think the scale argument is the stronger one. But both arguments lead to the conclusion that you can’t tell someone who uses AES to switch to 3DES because their setup may not be able to take it (rekey often enough or encrypt fast enough), and you can’t tell them to switch to ENCR_CAMELIA_CCM or ENCR_BLOWFISH because peers may not support these algorithms.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Thu, 2 Apr 2015 18:05:31 +0300

> On Mar 30, 2015, at 8:42 PM, Scott Fluhrer (sfluhrer) <[email-masked]> wrote:
> 
> 
> -----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
> 
>> 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. 
> 
> This idea about the multi-sender case works only if the there's a sender id somewhere in the encrypted packet.

You’re right. For some reason I thought that the SID in GDOI was implied rather than transmitted on the wire. Oh, well…

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

I think that for 256-bit keys it’s not that compelling. So the question is which is simpler: to do as AES-GCM does, or to set the salt to zero?

Yoav

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 03 Apr 2015 02:06:09 +0100

> I think that for 256-bit keys it’s not that compelling. So the question is which is simpler: to do as AES-GCM does, or to set the salt to zero?

It seems to me like a "truth in advertising" kind of thing: if we use a 
256-bit cipher then people using it expect 256-bit strength, rather than 
2^226. So I would be happy if we can get the salt without having to pay 
in packet length.

Thanks,
	Yaron

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 15 Apr 2015 10:48:10 +0300

Hi,

>> On Mar 30, 2015, at 5:39 PM, Yoav Nir <[email-masked]> wrote:
>>
>> Hi,
>>
>> 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.

First, the third option is absolutely inappropriate.
The draft suggests using Chacha+Poly for both ESP and IKE and
in case of IKE there are no replay counter that is unique in the context of 
IKE SA.
Message ID in IKE header _is_not_ unique - it can be repeated at least in 
two cases:
RFC6311 and RFC7383. So, the IKE Message ID is allowed to repeat and these
repetitions would be fatal for security.

Among the first two options I prefer the AES-GCM-like approach -
taking the needed 32 bits from the keying material.

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

I think UI issues are out of scope of this draft. The draft should make no 
recommendations of what PRF
should be used  (at least it should not make such recommendations with 
RFC2119 keywords).

Regards,
Valery.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 27 Apr 2015 11:14:55 -0400

Yoav Nir <[email-masked]> wrote:
    > 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.

So, in this case, if you wanted to not change your UI, maybe you would tell
the user to configure
    encryption-algorithm=Chacha20-Poly1305
    MAC=HMAC-SHA2
    DH=whatever

the MAC would not apply to IPsec at all?

I guess if we are deploying this algorithm with the concern that HMAC-SHA2/AES
might become weak, that it would seem odd to depend upon SHA2 as the PRF.
At least, users might not understand.

(noting that SHA2 != HMAC-SHA2, and also that the inputs to the PRF as not
very easily manipulated...)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-