Subject: [IPsec] RFC 4307bis

From: Yoav Nir <[email-masked]>
Date: Thu, 5 Nov 2015 01:39:24 +0900

Hi all.

I’ve uploaded the XML source of this document to github and submitted the first pull request:
https://github.com/ietf-ipsecme/drafts/pull/7/files <https://github.com/ietf-ipsecme/drafts/pull/7/files>

We had a side meeting about the algorithms specified in this draft and came up with some changes as you can see in the PR. In attendance were Paul H, David W, Paul W, Tero K, Tommy P, Daniel M and me.

I’ve also added a dummy paragraph for each algorithm. After I merge the pull request anyone (author or otherwise) can submit pull request. Hopefully the pre-existence of these paragraphs will prevent them from becoming conflicts. But I wouldn’t get my hopes up.

Anyway, please review the pull request and let me know if it’s problematic. If not, I will merge it early next week.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Mon, 9 Nov 2015 15:48:49 +0200

Hi

So I’ve merged the changes and submitted version -01 of the draft.

The stub paragraphs explaining the choices of algorithms are waiting to be filled. Please submit pull requests.

https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-ipsecme-rfc4307bis

Yoav

> On 4 Nov 2015, at 6:39 PM, Yoav Nir <[email-masked]> wrote:
> 
> Hi all.
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 09 Nov 2015 08:27:14 -0800

On 9 Nov 2015, at 5:48, Yoav Nir wrote:

> The stub paragraphs explaining the choices of algorithms are waiting 
> to be filled. Please submit pull requests.
>

This is an invitation to the WG to contribute to to this draft. If you 
are already familiar with GitHub, submit pull requests as Yoav said. If 
you are not yet familiar with GitHub, feel free to send text to the 
mailing list, and one of the authors will quickly enter those for you in 
GitHub. That is, being able to use GitHub is *not* required for you to 
contribute text.

--Paul Hoffman

---

From: Daniel Migault <[email-masked]>
Date: Mon, 9 Nov 2015 17:30:07 -0500

Hi,

You can view the latest changes here:

https://github.com/mglt
/drafts/blob/d2d31f6f9f0b4d57c8343826ad23fc546b99a467/draft-ietf-ipsecme
-rfc4307bis

We added some text to recommend the status of each recommended algorithms.

On Mon, Nov 9, 2015 at 11:27 AM, Paul Hoffman <[email-masked]> wrote:

> This is an invitation to the WG to contribute to to this draft. If you are
> already familiar with GitHub, submit pull requests as Yoav said. If you are
> not yet familiar with GitHub, feel free to send text to the mailing list,
> and one of the authors will quickly enter those for you in GitHub. That is,
> being able to use GitHub is *not* required for you to contribute text.
>
> --Paul Hoffman
>
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Nov 2015 00:33:51 +0200

Or for a diff-style view, see the pull request:
https://github.com/ietf-ipsecme/drafts/pull/8/files

Yoav

> On 10 Nov 2015, at 12:30 AM, Daniel Migault <[email-masked]> wrote:
> 
> Hi, 
> 
> https://github.com/mglt/drafts/blob/d2d31f6f9f0b4d57c8343826ad23fc546b99a467/draft-ietf-ipsecme-rfc4307bis
> 
> On Mon, Nov 9, 2015 at 11:27 AM, Paul Hoffman <[email-masked] <mailto:[email-masked]>> wrote:
> https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-ipsecme-rfc4307bis <https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-ipsecme-rfc4307bis>
> 
> This is an invitation to the WG to contribute to to this draft. If you are already familiar with GitHub, submit pull requests as Yoav said. If you are not yet familiar with GitHub, feel free to send text to the mailing list, and one of the authors will quickly enter those for you in GitHub. That is, being able to use GitHub is *not* required for you to contribute text.
> 
> --Paul Hoffman
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
>

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 10 Nov 2015 18:38:07 +0200

A few comments, sorry for not using GitHub.

I think the following text is kinda funny: "IKEv1 is out of scope of 
this document. IKEv1 is deprecated and the recommendations of this 
document MUST NOT be considered for IKEv1." We cannot tell people 
normatively what they can consider and what they cannot. Let's skip the 
capitalized MUST NOT.

The rationale for GCM describes why it's in the table, but seems to 
argue for a MUST (rather than the SHOULD that's in the table). I guess 
there's a reason why we don't have MUST, let's spell it out.

"As the overhead of AUTH_HMAC_SHA2_512 is negligible": suggest to change 
to "as the *additional* overhead".

I believe we should cite RFC 6194 when recommending against SHA-1.

"As it is not being deployed" - I suggest the softer "as it is not 
widely deployed" - we don't really know that nobody had ever deployed it.

"and now it is known to be weak at least for a nation state" - suggest 
to change to "and now it is known to be weak against a nation-state 
attacker".

Thanks,
	Yaron

On 11/10/2015 12:33 AM, Yoav Nir wrote:
>> On 10 Nov 2015, at 12:30 AM, Daniel Migault
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi,
>>
>>         The stub paragraphs explaining the choices of algorithms are
>>         waiting to be filled. Please submit pull requests.
>>
>>     This is an invitation to the WG to contribute to to this draft. If
>>     you are already familiar with GitHub, submit pull requests as Yoav
>>     said. If you are not yet familiar with GitHub, feel free to send
>>     text to the mailing list, and one of the authors will quickly
>>     enter those for you in GitHub. That is, being able to use GitHub
>>     is *not* required for you to contribute text.
>>
>>     --Paul Hoffman
>>
>>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Nov 2015 21:11:37 +0200

> On 10 Nov 2015, at 6:38 PM, Yaron Sheffer <[email-masked]> wrote:
> 
> I think the following text is kinda funny: "IKEv1 is out of scope of this document. IKEv1 is deprecated and the recommendations of this document MUST NOT be considered for IKEv1." We cannot tell people normatively what they can consider and what they cannot. Let's skip the capitalized MUST NOT.

Sounds reasonable, or even just saying that IKEv1 is out of scope (and therefore we don’t need to say another word about it)
> 
> The rationale for GCM describes why it's in the table, but seems to argue for a MUST (rather than the SHOULD that's in the table). I guess there's a reason why we don't have MUST, let's spell it out.

Yeah. GCM is faster than CBC+HMAC and can be used for more data. That’s important for IPSec, much less for IKE. More importantly, GCM for IPSec was defined in RFC 4106 in 2005 and is widely implemented. GCM for IKE was defined three years later in RFC 5282, and because the need for encryption performance and key longevity was much less got implemented a lot less. (My company’s product does not have it, for example). The focus of this document is interoperability without security mistakes, so GCM for IKE could be no more than a SHOULD.

> "As the overhead of AUTH_HMAC_SHA2_512 is negligible": suggest to change to "as the *additional* overhead".
> 

Recommending against? It’s at MUST- for both MAC and PRF (as HMAC), and we’re currently saying nothing about hashes in signatures.

> "As it is not being deployed" - I suggest the softer "as it is not widely deployed" - we don't really know that nobody had ever deployed it.

Agree. I, for one, implemented it, although I have no statistics telling me how many CP customers are actually configuring it. Probably none, because it’s (a) not the default, and (b) slower than GHash on all platforms, and (c) slower than HMAC-SHA1 on older platforms.

> "and now it is known to be weak at least for a nation state" - suggest to change to "and now it is known to be weak against a nation-state attacker".
> 
> Thanks,
> 	Yaron
>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 10 Nov 2015 23:01:37 +0200

> there's a reason why we don't have MUST, let's spell it out.

The reason for that is that it is not needed as IKEv2 SA is never used
to transmit huge amounts of data, thus the speed benefits you might
get from there is not needed. Also support for the combined modes do
require support for RFC5282, and there are implementations which have
not done that (as there is no benefits or need for them to implement
it).
-- 
[email-masked]

---

From: Daniel Migault <[email-masked]>
Date: Mon, 16 Nov 2015 11:05:00 -0500

Hi,

Thank you Yaron for your comments. Please find the new update ot the draft:

https://github.com/mglt/drafts/commit/0b2696ada172163930f3733a7c3155d49bca0002

Comment 1:
IKEv1 is out of scope of this document. IKEv1 is deprecated and the
recommendations of this documentmust not be considered for IKEv1.

I change MUST NOT in must not. I left the whole sentence as I beleive, it
provides the reason why IKEv1 is not in scope and state clearly that
applying considerations in this document to IKEv1 is a bad idea.

Comment 2:
I added some clarifying text on why not MUST. To me the obvious reason is
that an algorithm not mentioned in RFC4307 should not have a status greater
than SHOULD -- unless otherwise of course ;-). I though we had this
explanation somewhere, but maybe it is missing and should be added in the
intro for example.

I also provided dome explanation why ESP and IKEv2 are in a different race
which resulted in having AES-GCM not widely deployed for IKEv2

Comment 3:
"As it is not being deployed" as been replaced by "as it is not widely
deployed"

"and now it is known to be weak at least for a nation state" has been
changed to "and now it is known to be weak against a nation-state attacker".

Acknowledgement section has also been updated.

BR,
Daniel

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 16 Nov 2015 19:41:29 +0200

Looks good. One small correction:

many IKEv2 have not implemented => many IKEv2 implementations do not include

Thanks,
	Yaron

On 11/16/2015 06:05 PM, Daniel Migault wrote:
> I change MUST NOT in must not. I left the whole sentence as I beleive,
> it provides the reason why IKEv1 is not in scope and state clearly that
> I added some clarifying text on why not MUST. To me the obvious reason
> is that an algorithm not mentioned in RFC4307 should not have a status
> greater than SHOULD -- unless otherwise of course ;-). I though we had
> this explanation somewhere, but maybe it is missing and should be added
> in the intro for example.
>
> I also provided dome explanation why ESP and IKEv2 are in a different
> race which resulted in having AES-GCM not widely deployed for IKEv2
>
> Comment 3:
> On Tue, Nov 10, 2015 at 4:01 PM, Tero Kivinen <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Yaron Sheffer writes:
>     [email-masked] <mailto:[email-masked]>
>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 18 Nov 2015 16:04:40 -0500

Hi Yaron,

I just committed your correction. You are right this is much better.

BR,
Daniel

---

From: Daniel Migault <[email-masked]>
Date: Fri, 20 Nov 2015 11:28:21 -0500

Hi,

Please find an new update:
https://github.com/mglt/drafts/commit/1854f98fdc1ee340565d6758e8d4642500af1c2f

Change 1: AUTH_AES_XCBC_96 and PRF_AES128_CBC are set to SHOULD
instead of a MAY. I was suprised PRF was already SHOULD. In each case,
explanation text has been added.

Change 2: Titles of the subsections have also been updated to better
fit IANA designation.

Change 3: Sections have been re-ordered so from Typpe 1 / Type 3 /
Type 2 / Type 4 to Type 1/ Type 2/ Type 3 / Type 4.

Feel free to comment.

BR,

Daniel

On Wed, Nov 18, 2015 at 4:04 PM, Daniel Migault <[email-masked]

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 20 Nov 2015 09:23:25 -0800

Hello Daniel,

One minor typo: "PRF_AES128_CBC has been downgraded from SHOULD in RFC4307” should be "PRF_AES128_CBC has been downgraded from SHOULD+ in RFC4307"

On a broader note, many of the SHOULD algorithms (ENCR_AES_CCM_8, PRF_AES128_CBC, AUTH_AES-XCBC) are justified as being present for the purposes of Internet of Things devices. I tend to think that it would be more straightforward to have a separate document that explains the preferred algorithms for IoT devices (an IKEv2 profile for IoT, for example). However, if we do want to keep them in this document, I think it would help to have a section in the introduction to the document explaining the use case for the IoT devices and why they are now included in the bis document, whereas they were not relevant yet in RFC 4307. It may also be helpful to qualify the SHOULDs as pertaining more, perhaps, to servers; traditional VPN clients would generally not be interacting with IoT devices directly, and thus would have little reason to implement these algorithms.

Thanks,
Tommy

> On Nov 20, 2015, at 8:28 AM, Daniel Migault <[email-masked]> wrote:
> 
> Hi, 
> 
> https://github.com/mglt/drafts/commit/1854f98fdc1ee340565d6758e8d4642500af1c2f <https://github.com/mglt/drafts/commit/1854f98fdc1ee340565d6758e8d4642500af1c2f>
> 
> Change 1: AUTH_AES_XCBC_96 and PRF_AES128_CBC are set to SHOULD instead of a MAY. I was suprised PRF was already SHOULD. In each case, explanation text has been added.
> 
> Change 2: Titles of the subsections have also been updated to better fit IANA designation.
> Change 3: Sections have been re-ordered so from Typpe 1 / Type 3 / Type 2 / Type 4 to Type 1/ Type 2/ Type 3 / Type 4.
> 
> Feel free to comment.
> 
> BR, 
> Daniel
> 
> 
> 
> 
> On Wed, Nov 18, 2015 at 4:04 PM, Daniel Migault <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Yaron, 
> 
> On Mon, Nov 16, 2015 at 12:41 PM, Yaron Sheffer <[email-masked] <mailto:[email-masked]>> wrote:
> https://github.com/mglt/drafts/commit/0b2696ada172163930f3733a7c3155d49bca0002 <https://github.com/mglt/drafts/commit/0b2696ada172163930f3733a7c3155d49bca0002>
> 
> Comment 1:
> On Tue, Nov 10, 2015 at 4:01 PM, Tero Kivinen <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> 
>     Yaron Sheffer writes:
>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> 
>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 23 Nov 2015 11:20:25 -0500 (EST)

On Fri, 20 Nov 2015, Tommy Pauly wrote:

> On a broader note, many of the SHOULD algorithms (ENCR_AES_CCM_8, PRF_AES128_CBC, AUTH_AES-XCBC) are
> justified as being present for the purposes of Internet of Things devices. I tend to think that it would be
> more straightforward to have a separate document that explains the preferred algorithms for IoT devices (an
> IKEv2 profile for IoT, for example). However, if we do want to keep them in this document, I think it would
> help to have a section in the introduction to the document explaining the use case for the IoT devices and
> why they are now included in the bis document, whereas they were not relevant yet in RFC 4307. It may also
> be helpful to qualify the SHOULDs as pertaining more, perhaps, to servers; traditional VPN clients would
> generally not be interacting with IoT devices directly, and thus would have little reason to implement
> these algorithms.

I would suggest if we want to do that, to just use a [*] notation where
the [*] gets explained as "For interoperability with IoT clients only"

I would not want to leave it out because that will cause us to get
servers that won't support IoT devices.

Paul

---

From: Daniel Migault <[email-masked]>
Date: Thu, 26 Nov 2015 17:58:10 -0500

Hi Paul and Tommy,

Please find the new update of the draft:
1) text in the introduction has been added to specify the IoT use case, and
the motivations for having IoT considerations in this document.
2) IoT has been indicated in the tables with a comment specifying that the
requirement is for IoT interoperability. I was not able to have two lines
in the postamble. It seems <artwork> is not accepted as a children for
<postamble>
3) RFCs have been added in the reference section to enable xml2rfc to run
properly.

The update is available here:
https://github.com/mglt/drafts/commit/8c125fa2a82af21a44c5035c3311938d26443652

Feel free to comment update the text.

BR,
Daniel

On Mon, Nov 23, 2015 at 11:20 AM, Paul Wouters <[email-masked]> wrote:

>> justified as being present for the purposes of Internet of Things
>> devices. I tend to think that it would be

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 30 Nov 2015 09:20:38 -0800

Hi Daniel,

Thanks for making these changes! I think this makes the document much clearer.

With regards to the Introduction, it may be beneficial at this point to have subsections of the introduction to make it easier to parse. Right now there seem to be several topics that don’t necessarily flow into one another: explaining mandatory-to-implement algorithms, explaining which version of IKE is relevant, explaining deprecation of algorithms, and the IoT section.

Thanks,
tommy

> On Nov 26, 2015, at 2:58 PM, Daniel Migault <[email-masked]> wrote:
> 
> Hi Paul and Tommy, 
> 
> 1) text in the introduction has been added to specify the IoT use case, and the motivations for having IoT considerations in this document.
> 2) IoT has been indicated in the tables with a comment specifying that the requirement is for IoT interoperability. I was not able to have two lines in the postamble. It seems <artwork> is not accepted as a children for <postamble>
> 3) RFCs have been added in the reference section to enable xml2rfc to run properly.
> 
> https://github.com/mglt/drafts/commit/8c125fa2a82af21a44c5035c3311938d26443652 <https://github.com/mglt/drafts/commit/8c125fa2a82af21a44c5035c3311938d26443652>
> 
> On Mon, Nov 23, 2015 at 11:20 AM, Paul Wouters <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Daniel Migault <[email-masked]>
Date: Mon, 30 Nov 2015 13:22:14 -0500

Hi Tommy,

Thanks for the proposition Tommy, I thnik that will clearer to have
dedicated subsections in the intro. Here are the subsection I would
propose. I am waiting for the WG feed back before updating the draft, so
please let m eknow whether:

A) You like the idea of subsection in the intro
B) You DO NOT like the idea of subsections

C) If you like the following:
    c1) The need for mandatory-to-implement algorithms
    c2) The scope of the document (IKEv2 + implementer)
    c3) Updating algorithm status (deprecation of algorithms and the IoT
section)

D) If you have other propositions.

I will update the draft this week according to the responses.

BR,
Daniel

On Mon, Nov 30, 2015 at 12:20 PM, Tommy Pauly <[email-masked]> wrote:

> With regards to the Introduction, it may be beneficial at this point to
> have subsections of the introduction to make it easier to parse. Right now
> there seem to be several topics that don’t necessarily flow into one
> another: explaining mandatory-to-implement algorithms, explaining which
> version of IKE is relevant, explaining deprecation of algorithms, and the
> IoT section.
>
> Thanks,
> tommy
>
> 1) text in the introduction has been added to specify the IoT use case,
> and the motivations for having IoT considerations in this document.