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

From: [email-masked]
Date: Wed, 06 Apr 2016 09:59:45 -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-06.txt
	Pages           : 16
	Date            : 2016-04-06

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.  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-06

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

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: Tero Kivinen <[email-masked]>
Date: Wed, 6 Apr 2016 21:06:32 +0300

[email-masked] writes:
> 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.

This version includes the pre-shared keys (or "Shared Key Message
Integrity Code") in the authentication method table, as it specified
in the RFC7296 as mandatory to implement, so we want to say it MUST
here too. While I was doing that change, I noticed that we actually
update the RFC7296, as the 7296 section 4 has text saying that RSA
with key lengths of 1024 or 2048 are mandatory. In our section 4.1.1
we actually say that RSA key lengths with less than 2048 bits are
SHOULD NOT, so our recommendation are different than what is in the
RFC7296. After quick verify from our WG chair, I marked this document
as updating the RFC7296 (and added the missing fact that is obsoletes
rfc4307). The fact that this updates RFC7296 was also added in the
introduction.

In addition to those changes, this contains some fixes for some typos
etc (especially in the section 5 algoritms for IoT).

With these changes, I think this document is ready for the WGLC.

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

-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 6 Apr 2016 16:47:49 -0300

Hi,

my comments mostly are addressed, thanks.
The one still unaddressed is a strange comment "?SHOULD" in the last table
(Section 4.2). What does it mean?

Regards,
Valery.

-----Original Message----- 
From: Tero Kivinen
Sent: Wednesday, April 6, 2016 3:06 PM
To: [email-masked]
Cc: [email-masked] ; [email-masked]
Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt

-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 Apr 2016 01:17:59 +0300

> (Section 4.2). What does it mean?

I think that is leftover from our internal discussions, i.e. whether
we should mark that ecdsa-with-sha512 as SHOULD instead of MAY.

I think MAY is fine, so unless people think we should pick that too
with SHOULD, I will remove that in next version. I do not think we
need to do it now, we can do the WGLC with the draft we have now, and
remove it after that.

Other thing I want people to think is whether we should say something
else about the AES key sizes, i.e. we now say MUST for 128-bit, MAY
for 256-bit and "192-bit keys can safely be ignored." One proposal
that was done was to change that MUST for 128-bit, SHOULD for 256-bit,
and perhaps even SHOULD NOT for 192-bit.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 7 Apr 2016 10:17:01 -0300

After re-reading the draft I think that I'm also a bit unhappy with the way 
the last table
(Section 4.2) is introduced. The draft says that this table is:

   Recommendation of Authentication Method described in [RFC7427]
   notation.

However, the values from this table are just examples in RFC7427.
Why exactly these algorithms were selected for recommendation?
What about others (EdDSA, GOST etc)? I understand that
the algorithms listed were probably most popular (at least some of them)
at the time RFC 7427 ws written. But why continue to maintain
this list, when it is just a list of examples in RFC7427?

Well, I understand that some recommendations should be given.
But probably only those signing algorithms that have non-MAY
status should be listed and a note should be added that
all others are MAY (that will refer to any unlisted signature
algorithm)?

What others think?

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 Apr 2016 17:09:05 +0300

Valery Smyslov writes:
> After re-reading the draft I think that I'm also a bit unhappy with
> the way the last table (Section 4.2) is introduced. The draft says
> that this table is:
> 

Note, that most of them are MAY, so we should really remove them from
this draft. And they are the algorithms we expect people to use.

> What about others (EdDSA, GOST etc)?

EdDSA is just about getting oid, so we cannot really list it here. For
GOST I have no idea what the oid would be. Both of them would be in
the same level as sha256WithRSAEncryption, sha384WithRSAEncryption,
sha512WithRSAEncryption, sha512WithRSAEncryption, dsa-with-sha256,
ecdsa-with-sha384, and ecdsa-with-sha512.

> I understand that the algorithms listed were probably most popular
> (at least some of them) at the time RFC 7427 ws written. But why
> continue to maintain this list, when it is just a list of examples
> in RFC7427?

One of the reason RF7427 lists that many oids, is that there is no
centralized registry for them. I.e. you cannot go somewhere and get
list of OIDs you can use for signatures, so RF7427 tried to collect
all signature algortihms people might use.

Anyways I think we need to remove all that is not SHOULD or SHOULD NOT
from the list, i.e., everything we have MAY recommendation in the
list. 

> all others are MAY (that will refer to any unlisted signature

I agree on removing all MAY algorithms, we do not need note, as that
is already said in the section 1.2.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 7 Apr 2016 11:26:23 -0300

> this draft.

That's what I suggest.

> from the list, i.e., everything we have MAY recommendation in the

Fine. That will resolve my concern. 

> is already said in the section 1.2.

OK.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 7 Apr 2016 11:52:43 -0300

Fine with me

Sent from my iPhone

> On Apr 7, 2016, at 11:09, Tero Kivinen <[email-masked]> wrote:
> 
> Valery Smyslov writes: