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

From: [email-masked]
Date: Sun, 26 Apr 2015 13:48:34 -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 IKE & IPsec
        Author          : Yoav Nir
	Filename        : draft-ietf-ipsecme-chacha20-poly1305-04.txt
	Pages           : 11
	Date            : 2015-04-26

Abstract:
   This document describes the use of the ChaCha20 stream cipher along
   with the Poly1305 authenticator, combined into an AEAD algorithm for
   the Internet Key Exchange protocol (IKEv2) and 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-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-04

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: Sun, 26 Apr 2015 23:50:28 +0300

Hi.

At Paul’s request I have added examples in appendix A and appendix B.

At Yaron’s request I have added some text about the key and salt derivation in IKE (as opposed to IPsec)

Yoav

> On Apr 26, 2015, at 11:48 PM, [email-masked] wrote:
> 
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Sun, 26 Apr 2015 23:52:02 +0300

Oh, and one more thing: I’d really appreciate it if somebody checked my examples.  All I can be sure of is that they work in my code.

Yoav

> On Apr 26, 2015, at 11:50 PM, Yoav Nir <[email-masked]> wrote:
> 
> Hi.
>

---

From: Martin Willi <[email-masked]>
Date: Mon, 27 Apr 2015 13:02:52 +0200

Yoav,

> Oh, and one more thing: I’d really appreciate it if somebody checked my
> examples.  All I can be sure of is that they work in my code.

I've hit two issues when verifying the IKEv2 example in our code:

>From appendix B:

> Padding as required by RFC 7296 is 4 bytes long.

Do we have such a padding requirement for IKEv2? For ChaCha20 we have no
requirement for input lengths, so no padding is needed. While we have 4
byte padding in ESP, I don't think this is true for IKEv2 Encrypted
Payloads, is it?

>From RFC 7296 3.14:

>    o  Padding MAY contain any value chosen by the sender, and MUST have
>       a length that makes the combination of the payloads, the Padding,
>       and the Pad Length to be a multiple of the encryption block size.
>       This field is encrypted with the negotiated cipher.
> 
>    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.

So while the used padding is not invalid, it is not what we SHOULD use,
and if so probably not a good example. Maybe we should also add a note
about IKEv2 padding to section 3?

The other issue I've seen is about the Next Payload:

>   Encrypted Payload:
>   000  00 00 00 2c 10 11 12 13 14 15 16 17 61 03 94 70  ...,........a..p

The Next Payload field in the Encrypted Payload is 0. However, RFC 7296
defines:

> Next Payload - The payload type of the first embedded payload.

So I think Next Payload should be Notify (0x29).

Kind Regards
Martin

---

From: Yoav Nir <[email-masked]>
Date: Tue, 28 Apr 2015 00:27:28 +0300

Hi, Martin. See inline.

> On Apr 27, 2015, at 2:02 PM, Martin Willi <[email-masked]> wrote:
> 
> Yoav,
> 

This is actually quite unfortunate text. Fields must be aligned to block size only for CBC. Aligning AES-GCM to 16 bytes and ChaCha20-Poly1305 to 64 bytes would be totally arbitrary, yet that is what the MUST requirement in the first bullet seems to be saying. I don’t even know what “proper alignment” means for a cipher such as this. If anything is proper alignment, then the value that fulfills the SHOULD requirement is zero (with no padding bytes). For section 3, I could add a text that echoes the second bullet:

   The sender SHOULD include no padding and set the Pad Length field to zero. The receiver MUST accept any length of padding.

Sounds good?

> So I think Next Payload should be Notify (0x29).

Yes, you’re right. I’ve fixed this in my working draft. I should publish again in a day or two.

Thanks.

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Mon, 27 Apr 2015 19:49:31 -0400 (EDT)

>   The sender SHOULD include no padding and set the Pad Length field to zero. The receiver MUST accept any length of padding.

Not really?

Choices like that make me nervous that an attacker can tweak the padding
option. Who knows what oracle that can become in the future. There MUST
only be one way to do things. So I would rather see:

 	The sender MUST NOT include padding and set the Pad Length field to
 	zero. The receiver MUST reject a non-zero Pad Length field.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Tue, 28 Apr 2015 06:51:46 +0300

> On Apr 28, 2015, at 2:49 AM, Paul Wouters <[email-masked]> wrote:
> 

I’m OK with that as well, (though I would phrase it in the positive “The sender MUST include no padding and set …”), but that goes against RFC 7296. Specifically your second sentence turns a “MUST accept” into a “MUST reject”.

Yoav

---

From: Martin Willi <[email-masked]>
Date: Tue, 28 Apr 2015 10:00:10 +0200

Hi Yoav,

> I don’t even know what “proper alignment” means for a cipher such as
> this. If anything is proper alignment, then the value that fulfills the
> SHOULD requirement is zero (with no padding bytes). For section 3, I
> could add a text that echoes the second bullet:
> 
>    The sender SHOULD include no padding and set the Pad Length field to
>    zero. The receiver MUST accept any length of padding.

I agree, and think that text is fine.

> publish again in a day or two.

Great. I can confirm that both the ESP and the IKEv2 examples in -06 now
match the output of my test cases.

I think the draft looks fine now, and I support to go on with it.

Kind regards
Martin

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Apr 2015 11:05:31 -0400

> zero. The receiver MUST reject a non-zero Pad Length field.

No, the sender should be able to add as much padding as they want whenever
they want.   And "reject" is the wrong operation (that implies an ICMP or
other messages).  If you want to say something, the correct operation is
ignore (=silently drop).

If the attacker can tweak the padding, they must be inside of the sender,
IPsec has the padding inside the encryption and authentication, unlike some
other algorithms.

This is necessary to defeat traffic analysis where one looks at timing of
very short packets (which might be keystrokes).

It also lets the sender send a NH=0 chaff packet with a bunch of padding so
that it looks like a real data.

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