Subject: Re: [IPsec] RFC 4307bis

From: Daniel Migault <[email-masked]>
Date: Wed, 2 Dec 2015 16:01:45 -0600

Hi,

Please se the current version of the document with the subsection in the
Introduction.

https://github.com/mglt/drafts/commit/ef72ea482af74d4226d3059237024f63d0add01b

The subsections are:
   1.1 Updating Mandatory to Implement Algorythms
   1.2 Algorithm Status Update Policy
   1.3 Audience of the Document

Feel free to provide any comment. I beleive we have addressed all comments
we received.

I am finding the terminology mandatory-to-implement maybe a bit misleading
for status like MAY or a MUST NOT. Any suggestion to clarify that?

BR,
Daniel

On Mon, Nov 30, 2015 at 12:22 PM, Daniel Migault <
[email-masked]> wrote:

> 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:
>
>> 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,
>>
>> 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:
>>
>>> 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
>>>
>>>
>>> _______________________________________________
>>> IPsec mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>
>>
>>
>>
>> _______________________________________________
>> IPsec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>>
>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 2 Dec 2015 16:24:40 -0600

Hi,

Please find the updated version with the new section titles suggested by
Yaron:
1.1 Updating Mandatory to Implement Algorithms
1.2 Updating Algorithm Requirement Levels
1.3 Document Audience

BR,
Daniel
https://github.com/mglt/drafts/commit/ffb6e9ad82bc952f3a891de232cd10be353878a9

On Wed, Dec 2, 2015 at 4:01 PM, Daniel Migault <[email-masked]>
wrote:

>>> 3) RFCs have been added in the reference section to enable xml2rfc to
>>> run properly.
>>>

---

From: John Mattsson <[email-masked]>
Date: Fri, 4 Dec 2015 09:45:21 +0000

Hi,

-Agree with your comment on “mandatory-to-implement”. I think the Introduction should be changed, and I suggest using something like the text used in RFC7321 “Algorithm Implementation Requirements and Usage Guidance”. RFC7321 also has a more explaining title.

- I think 1024-bit MODP should be “SHOULD NOT-” as it seems to be agreement that is should be “MUST NOT” in the next update. Might may sense to define “+” and “-” instead of “SHOULD+, SHOULD-, MUST-”

- I think “Curve25519” should be included as “MAY” or “MAY+”, even if nobody has implemented it yet, it seems like the obvious choice long-term.

Cheers,
John

From: IPsec <[email-masked]<mailto:[email-masked]>> on behalf of Daniel Migault <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 2 December 2015 23:24
To: Tommy Pauly <[email-masked]<mailto:[email-masked]>>
Cc: IPsecME WG <[email-masked]<mailto:[email-masked]>>, Paul Wouters <[email-masked]<mailto:[email-masked]>>
Subject: Re: [IPsec] RFC 4307bis

Hi,

Please find the updated version with the new section titles suggested by Yaron:
1.1 Updating Mandatory to Implement Algorithms
1.2 Updating Algorithm Requirement Levels
1.3 Document Audience

BR,
Daniel

On Wed, Dec 2, 2015 at 4:01 PM, Daniel Migault <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Please se the current version of the document with the subsection in the Introduction.

The subsections are:

Feel free to provide any comment. I beleive we have addressed all comments we received.

I am finding the terminology mandatory-to-implement maybe a bit misleading for status like MAY or a MUST NOT. Any suggestion to clarify that?

BR,
Daniel

On Mon, Nov 30, 2015 at 12:22 PM, Daniel Migault <[email-masked]<mailto:[email-masked]>> wrote:
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:

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)

BR,
Daniel

On Mon, Nov 30, 2015 at 12:20 PM, Tommy Pauly <[email-masked]<mailto:[email-masked]>> wrote:
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]<mailto:[email-masked]>> wrote:

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.

BR,
Daniel

On Mon, Nov 23, 2015 at 11:20 AM, Paul Wouters <[email-masked]<mailto:[email-masked]>> wrote:
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.

Paul

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Daniel Migault <[email-masked]>
Date: Thu, 10 Dec 2015 18:18:50 -0500

Hi John,

Thank you for your inputs. In order to update the document any further I
would like to get feed backs from the WG. Please provide your comments so I
can update the document appropriately next week.

1) MTI?
Are there any opinion to replace Mandatory to implement by something like
"Algorithm Implementation Requirements and Usage Guidance"or close to. This
designation seems more in scope with the different status.

2) 1024-bit MODP SHOULD NOT- ?
The current draft set 1024-bit MODP Group as SHOULD NOT with the following
explanation:

"""Group 2 or 1024-bit MODP Group is downgraded from MUST- to SHOULD NOT.
It was specified earlier, and now it is known to be weak against a nation
state attack, so its security margin is considered too narrow."""

My understanding from the discussion at the IETF94 was that we are trying
to avoid the +/- notation but instead clarify the status with some
additional text. The current version only use the +/- notation for
AUTH_HMAC_SHA2_512_256
SHOULD+. Here are my question for the WG:
    a) Do we want to keep the notation +/- ?
    b) if not would people agree with AUTH_HMAC_SHA2_512_256 set to SHOULD

Depending on the above outputs, are there any opinion for:
   c) Changing the status from SHOULD NOT to SHOULD NOT + ?
   d) Explicitely mentionning in the text that we expect it to downgraded
to MUST NOT in the near future.

3) +/- notations?
If we keep the +/- notations, I agree we should define +/- only.I will
change that unless some people think it is a bad idea.

4) Curve25519 ?
Curve25519 is by default set to MAY. If we still have the -/+ notation
would people agree to have MAY+ for its status. If I remember correctly, we
did not mentionned Curve25519 to SHOULD as it is not yet widely deployed.
By default all non mentioned algorithms are set to MAY. Maybe having MAY+
would be good alternative to show what we expect next and enable
implementer to anticipate. Here are my questions:
    e) Should we upgrade Curve25519 to MAY+?

BR,
Daniel

On Fri, Dec 4, 2015 at 4:45 AM, John Mattsson <[email-masked]>
wrote:

> Hi,
>
> -Agree with your comment on “mandatory-to-implement”. I think the
> Introduction should be changed, and I suggest using something like the text
> used in RFC7321 “Algorithm Implementation Requirements and Usage Guidance”.
> RFC7321 also has a more explaining title.
>
> - I think 1024-bit MODP should be “SHOULD NOT-” as it seems to be
> agreement that is should be “MUST NOT” in the next update. Might may sense
> to define “+” and “-” instead of “SHOULD+, SHOULD-, MUST-”
>
> - I think “Curve25519” should be included as “MAY” or “MAY+”, even if
> nobody has implemented it yet, it seems like the obvious choice long-term.
>
> Cheers,
> John
>
> From: IPsec <[email-masked]> on behalf of Daniel Migault <
> [email-masked]>
> To: Tommy Pauly <[email-masked]>
> Cc: IPsecME WG <[email-masked]>, Paul Wouters <[email-masked]>
> On Wed, Dec 2, 2015 at 4:01 PM, Daniel Migault <
>> I am finding the terminology mandatory-to-implement maybe a bit
>> misleading for status like MAY or a MUST NOT. Any suggestion to clarify
>> that?
>>
>> BR,
>> Daniel
>>
>>>> On Nov 26, 2015, at 2:58 PM, Daniel Migault <

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 17 Dec 2015 14:46:40 +0200

> designation seems more in scope with the different status.

I agree on that. 

> """Group 2 or 1024-bit MODP Group is downgraded from MUST- to SHOULD NOT. It
> was specified earlier, and now it is known to be weak against a nation state
> attack, so its security margin is considered too narrow."""
> 
> My understanding from the discussion at the IETF94 was that we are trying to
> avoid the +/- notation but instead clarify the status with some additional
> text.

Actually I think it might be better to just use text, and get rid of
the + and -.

> The current version only use the +/- notation for AUTH_HMAC_SHA2_512_256

I would get rid of the notation, as we now have text explaining more
about the status of algorithms, and that text can express things more
clearly than the + and - can.

>     b) if not would people agree with AUTH_HMAC_SHA2_512_256 set to

I think it should be SHOULD. 

>    d) Explicitely mentionning in the text that we expect it to downgraded to
> MUST NOT in the near future.

I do not know if it is near future, but sometime in future. And yes, I
think we should state that. 

> 3) +/- notations?
> If we keep the +/- notations, I agree we should define +/- only.I will change
> that unless some people think it is a bad idea.
> 
> 4) Curve25519 ?
> Curve25519 is by default set to MAY. If we still have the -/+ notation would
> people agree to have MAY+ for its status. If I remember correctly, we did not 
> mentionned Curve25519 to SHOULD as it is not yet widely deployed. By default
> all non mentioned algorithms are set to MAY. Maybe having MAY+ would be good
> alternative to show what we expect next and enable implementer to anticipate.
> Here are my questions:

I think we can have Curve25519 listed as MAY, with text explaining
that if it gets widely implemented then it most likely will be
upgraded to should or even must in the future.

Btw, there is quite a lot of changes in the draft now, so I think it
would be good idea to publish 02 version now, as drafts are easier to
read than the changes in some repository.
-- 
[email-masked]