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 <john.matts...@ericsson.com>
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 <ipsec-boun...@ietf.org> on behalf of Daniel Migault <
> daniel.miga...@ericsson.com>
> Date: Wednesday 2 December 2015 23:24
> To: Tommy Pauly <tpa...@apple.com>
> Cc: IPsecME WG <ipsec@ietf.org>, Paul Wouters <p...@nohats.ca>
> 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
>
> https://github.com/mglt/drafts/commit/ffb6e9ad82bc952f3a891de232cd10be353878a9
>
> On Wed, Dec 2, 2015 at 4:01 PM, Daniel Migault <
> daniel.miga...@ericsson.com> wrote:
>
>> 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 <
>> daniel.miga...@ericsson.com> 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 <tpa...@apple.com> 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 <
>>>> daniel.miga...@ericsson.com> 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 <p...@nohats.ca> 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
>>>>> IPsec@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> IPsec mailing list
>>>> IPsec@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>>
>>>>
>>>
>>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
