Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-10.txt

From: [email-masked]
Date: Wed, 20 Jul 2016 03:30:25 -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 of the IETF.

        Title           : Algorithm Implementation Requirements and Usage Guidance for IKEv2
        Authors         : Yoav Nir
                          Tero Kivinen
                          Paul Wouters
                          Daniel Migault
	Filename        : draft-ietf-ipsecme-rfc4307bis-10.txt
	Pages           : 17
	Date            : 2016-07-20

Abstract:
   The IPsec series of protocols makes use of various cryptographic
   algorithms in order to provide security services.  The Internet Key
   Exchange (IKE) protocol is used to negotiate the IPsec Security
   Association (IPsec SA) parameters, such as which algorithms should be
   used.  To ensure interoperability between different implementations,
   it is necessary to specify a set of algorithm implementation
   requirements and usage guidance to ensure that there is at least one
   algorithm that all implementations support.  This document defines
   the current algorithm implementation requirements and usage guidance
   for IKEv2 and does minor cleaning up of IKEv2 IANA registry.  This
   document does not update the algorithms used for packet encryption
   using IPsec Encapsulated Security Payload (ESP).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-10

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: John Mattsson <[email-masked]>
Date: Sun, 24 Jul 2016 22:59:40 +0000

Hi,

I reread  draft-ietf-ipsecme-rfc4307bis-10, I think this is very well
written and definatly ready for WGLC.

Some comments:

- Section 4.1
Given the existing text “Digital Signature [RFC7427] is expected to be
promoted”, I think authentication method number 14 should be “SHOULD+”

- Section 4.1
Given the existing text “It is expected to be downgraded”, I think
authentication method number 1 should be “MUST-”.

- Section 4
Any reason that authentication method 10 (ECDSA with SHA-384 on the P-384
curve) and 11 (ECDSA with SHA-512 on the P-521 curve) are SHOULD while
authentication method 14 (Digital Signature) with ecdsa-with-sha384 and
ecdsa-with-sha512 are MAY?

Capitalisation:

- Section 2
“IoT       stands” -> “IoT	Stands”

- Section 4.1.1
“Recommendations for RSA key length” -> Recommendations for RSA Key Length

Cheers,
John

On 20/07/16 12:30, "IPsec on behalf of [email-masked]"
<[email-masked] on behalf of [email-masked]> wrote:

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

---

From: Paul Wouters <[email-masked]>
Date: Mon, 25 Jul 2016 04:07:25 -0400 (EDT)

> promoted”, I think authentication method number 14 should be “SHOULD+”

It should be, but since RFC7427 was not widely adopted yet, we refrained
from doing so. We are hopeful it will see more adoption and for it to
go that way. But we feel a plus should signify a move that is already
visible, and for RFC7427 it is not visible yet.

> authentication method number 1 should be “MUST-”.

I agree, but some people at ietf96 felt that we must always have an
unqualified MUST in there. I also think a MUST- would be better because
it still signifies a MUST but indicates we want to very slowly start
deprecating it. I expect in the next version that will go to SHOULD-
regardless of whether it is a MUST or MUST- one.

> ecdsa-with-sha512 are MAY?

I believe this was due to ECDSA being considered an older variant of
ECC and if you do the shint new stuff of RFC7427, you can and should
use better ECC algorithms too (like EdDSA)

> “Recommendations for RSA key length” -> Recommendations for RSA Key Length

We will pull these two changes into the next version.

Paul