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

From: [email-masked]
Date: Wed, 11 May 2016 05:38:30 -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-08.txt
	Pages           : 16
	Date            : 2016-05-11

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-08

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

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, 11 May 2016 15:47:39 +0300

This version includes changes from the WGLC.

Changes include:

- In section 1.2 changed the "set to MAY" to "denoted here as MAY"
  (Yaron).

- Added text to end of 1.2: "Requirement levels that are marked as
  "IoT" apply to IoT devices and to server-side implementations that
  might presumably need to interoperate with them, including any
  general- purpose VPN gateways." (Yaron).

- Removed text from section 1.3 saying that recommendations are useful
  for users, i.e., the text now says: "On the other hand, comments
  from this document are also expected to be useful for such users.".
  I.e., this tries to clarify that recommendations are for
  implementors, the comments for algorithms are something that are
  useful for users too. (Quynh)

- Reformatted the AUTH_DES_MAC text a bit. Mention that both MD5 and
  DES are being deprecated. Even if the last sentence only covers MD5
  it does not matter, as it clearly says that sentence covers MD5
  only. (Yaron) Current text is 

   AUTH_DES_MAC, AUTH_HMAC_MD5_96, and AUTH_KPDK_MD5 were not mentioned
   in RFC4307 so their default status ware MAY.  They have been
   downgraded to MUST NOT.  There is an industry-wide trend to deprecate
   DES and MD5.  MD5 support is being removed from cryptographic
   libraries in general because its non-HMAC use is known to be subject
   to collision attacks, for example as mentioned in [TRANSCRIPTION].

- Changed 4.2 text has been changed to clarify that all these are only
  for "Digital Signatures authentication method" (Valery)

- Changed RSASSA-PSS with SHA-256 to MUST from SHOULD as now it is
  clear that this table is only applied if Digital Signature
  authentication method is implemented. (Valery)

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

-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Wed, 11 May 2016 08:49:55 -0400 (EDT)

> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-08

Thanks Tero,

My only question is regarding the table formerly known as table 9.

If we concluded that RFC7427 is not widely implemented yet, is there
any reason to keep 5 SHOULD NOT entries there instead of making those
MUST NOT ?

Paul

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Wed, 11 May 2016 15:11:42 +0000

Hi all,

As I explained before, the group numbers  5 and 2 should become "MUST NOT" because they don't provide 112 bits of security.

And, all signatures with SHA1 should become "MUST NOT".

Regards,
Quynh.
________________________________________
From: IPsec <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Wednesday, May 11, 2016 8:38:30 AM
To: [email-masked]
Cc: [email-masked]
Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt

Abstract:

---

From: Paul Wouters <[email-masked]>
Date: Wed, 11 May 2016 11:50:09 -0400 (EDT)

> As I explained before, the group numbers  5 and 2 should become "MUST NOT" because they don't provide 112 bits of security.

Checking RFC 4307, group 2 was MUST- so it should go to SHOULD NOT but
_maybe_ can go to MUST NOT.

For some reason, group 5 was not listed in RFC 4307, so it mist have been a MAY,
which would allow us to go to MUST NOT. But it would be weird to have
group 2 SHOULD NOT and group 5 MUST NOT.

Personally, I have no problem with IKEv2 dropping group 2/5. All IKEv2
clients should have defaulted to group 14 for years now. Obviously, I
won't kick group 2/5 out of IKEv1.

> And, all signatures with SHA1 should become "MUST NOT".

SHA1 was a MUST, so we cannot go to MUST NOT. Instead of MUST- we could
go to SHOULD NOT. But I don't know how widespread SHA1 is with IKEv2.

Paul

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Wed, 11 May 2016 17:58:20 +0000

Hi Paul,

We should explain that current MTI group is the group 2. However, users shall not use that group and the group. We should create a similar statement for SHA1 in signatures.

If a system has interoperability issue with the requirement, a user needs to upgrade his or her system. If she or he ignores our requirement/recommendation and uses the group 2 (or group 5), none of us can stop them from doing that and our requirement would become a great reminder to her or him that what he or she is doing is bad and does not comply with our recommendations.

Regards,
Quynh.

________________________________________
From: Paul Wouters <[email-masked]>
Sent: Wednesday, May 11, 2016 11:50:09 AM
To: Dang, Quynh (Fed)
Cc: IPsecME WG
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 11 May 2016 14:15:21 -0400 (EDT)

On Wed, 11 May 2016, Dang, Quynh (Fed) wrote:

> We should explain that current MTI group is the group 2.

But it is not? The only MUST entry for Type 4 is Group 14 (modp2048)
Group 2 is SHOULD NOT.

>  However, users shall not use that group and the group. We should create a similar statement for SHA1 in signatures.

What users should or should not do and what implementations offer as
default or not are out of scope for this document as explained in:

https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-07#section-1.3

    The recommendations of this document mostly target IKEv2 implementers
    as implementations need to meet both high security expectations as
    well as high interoperability between various vendors and with
    different versions.  Interoperability requires a smooth move to more
    secure cipher suites.  This may differ from a user point of view that
    may deploy and configure IKEv2 with only the safest cipher suite.  On
    the other hand, comments and recommendations from this document are
    also expected to be useful for such users.

In other words, the document sets the lowest acceptable bar. An
implementation only implementing MUST algorithms is obviously
more secure than an implementation that implements SHUOLD NOT
algorithms.

Paul

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Wed, 11 May 2016 19:01:33 +0000

Hi Paul, 

I meant implementations conforming to the RFC 4307 which implemented the group 2. However, users must not use the group 2 because it is not secure at this time. 

If we want users not to use bad options, then we must prohibit them with "MUST  NOT" for implementations. There are no reasons for saying "allowed" to implement them while asking users not to use them unless we want to say to users they are allowed to be used. 

This text "On the other hand, comments and recommendations from this document are also expected to be useful for such users." and the document says that  the groups 2 and 5 are allowed  "SHOULD NOT, not MUST NOT".  All of these seem to tell users that these groups are allowed to use. 

Regards,
Quynh. 

________________________________________
From: Paul Wouters <[email-masked]>
Sent: Wednesday, May 11, 2016 2:15 PM
To: Dang, Quynh (Fed)
Cc: IPsecME WG
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 11 May 2016 15:47:29 -0400 (EDT)

> I meant implementations conforming to the RFC 4307 which implemented the group 2. However, users must not use the group 2 because it is not secure at this time.

I disagree that group 2 is not secure. If it was _really_ not secure it
would be a candidate for an urgent MUST NOT.

> If we want users not to use bad options

That is outside the scope of this document.

> This text "On the other hand, comments and recommendations from this document are also expected to be useful for such users." and the document says that  the groups 2 and 5 are allowed  "SHOULD NOT…

that's not how I interpret that. I interpret that as "avoid when
possible, there if really needed".

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 12 May 2016 13:05:14 +0300

Dang, Quynh (Fed) writes:
> As I explained before, the group numbers  5 and 2 should become
> "MUST NOT" because they don't provide 112 bits of security. 

And the reply was that as group 2 is the currently used group,
changing them to MUST NOT now would cause huge issues for the users.

And the comments for users says that "It is expected in the near
future to be downgraded to MUST NOT.", so the users knows that they
should move away from it. 

I do not think we can do anything for this now, in the next version of
this document (in 2-3 years) we will make them MUST NOT.

> And, all signatures with SHA1 should become "MUST NOT".

We currently do not really have a way to do that. The most commonly
used signature method now is "RSA Digital Signature" with SHA1, but
there is no negotiation of hash algorithm to be used in there, thus
making it MUST NOT there would cause big interoperability issues, as
peers cannot agree not to use SHA1.

In the Digital Signature authentication method, there is a method to
negotiate hash algorithms, and there we say that SHA1 is SHOULD NOT,
which is aligned with other recommendations for SHA1 in the draft. We
could change them to MUST NOT, as people have not implemented Digital
Signature authentication method yet, so they can also implement SHA2
(and RSASSA-PSS) while implementing it and there the peers can
negotiate the hash algorithm to be used. 

So here we cannot get rid of the most commonly used SHA1 signature
method, but we can make it so that when people do implement Digital
Signature authentication method, they will not implement SHA1 based
signatures at all, and only do the safe hash algorithms.

I.e. change 4.2 to say:

              +--------+-------------+------------+---------+
              | Number | Description | Status     | Comment |
              +--------+-------------+------------+---------+
              | 1      | SHA1        | MUST NOT   |         |
              | 2      | SHA2-256    | MUST       |         |
              | 3      | SHA2-384    | MAY        |         |
              | 4      | SHA2-512    | SHOULD     |         |
              +--------+-------------+------------+---------+

and

       +------------------------------------+------------+---------+
       | Description                        | Status     | Comment |
       +------------------------------------+------------+---------+
       | RSASSA-PSS with SHA-256            | MUST       |         |
       | ecdsa-with-sha256                  | SHOULD     |         |
       | sha1WithRSAEncryption              | MUST NOT   |         |
       | dsa-with-sha1                      | MUST NOT   |         |
       | ecdsa-with-sha1                    | MUST NOT   |         |
       | RSASSA-PSS with Empty Parameters   | MUST NOT   |         |
       | RSASSA-PSS with Default Parameters | MUST NOT   |         |
       +------------------------------------+------------+---------+
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 12 May 2016 13:21:13 +0300

Dang, Quynh (Fed) writes:
> I meant implementations conforming to the RFC 4307 which implemented
> the group 2. However, users must not use the group 2 because it is
> not secure at this time.  

Implementation conforming to RFC4307 can decide NOT to implement
group 2 or SHA1.

You have to remember what SHOULD NOT means:

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

In this case the valid reasons why implementations want to implement
group 2 is because not implementing it causes interoperability issues
with old version.

This does NOT give any guidance or recommendations for the users. We
are talking mostly about the implementors here not users when we make
those recommendations. 

> If we want users not to use bad options, then we must prohibit them
> with "MUST NOT" for implementations. There are no reasons for saying
> "allowed" to implement them while asking users not to use them
> unless we want to say to users they are allowed to be used.

If implementation prohibits them using it and users notice this cause
interoperability issue, users will simply switch to some other product
that works, i.e., SSL 3.0 VPN, IKEv1, or simply do not upgrade to the
new version as it breaks things. 

> This text "On the other hand, comments and recommendations from this
> document are also expected to be useful for such users." and the
> document says that the groups 2 and 5 are allowed "SHOULD NOT, not
> MUST NOT". All of these seem to tell users that these groups are
> allowed to use.

This text was changed in the latest draft, based on your comments. Now
it says:

1.3.  Document Audience

   the other hand, comments from this document are also expected to be
   useful for such users.

I.e., now it does not even claim to give any recommendations for the
users, it just says that the comments we have for the algorithms are
something that might also be useful for such users.

If you think this is not clear enough, we can change it to say:

1.3.  Document Audience

   may deploy and configure IKEv2 with only the safest cipher suite.

   This document does not give any recommendations for the use of
   algorithms, it only gives implementation recommendations for
   implementations. The use of algorithms by users is dictated by the
   security policy requirements for that specific user, and are
   outside the scope of this document.
-- 
[email-masked]

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Thu, 12 May 2016 12:31:53 +0000

Hi Tero and Paul,

I like your proposed new text. I also recommend to add something like this: "The group 2 and any other cryptographic algorithms which are expected to provide around 80 bits of security strength are considered insecure mechanisms." Unless we can describe a complete use case, then we could be able to say whether or not the group 2 is acceptable in that case. Without that, we can say either it is secure or not secure, there are nothings in between.

Regards,
Quynh.

________________________________________
From: Tero Kivinen <[email-masked]>
Sent: Thursday, May 12, 2016 6:21:13 AM
To: Dang, Quynh (Fed)
Cc: [email-masked]; IPsecME WG
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt

1.3.  Document Audience

1.3.  Document Audience

---

From: Paul Wouters <[email-masked]>
Date: Thu, 12 May 2016 09:46:58 -0400 (EDT)

> I like your proposed new text. I also recommend to add something like this: "The group 2 and any other cryptographic algorithms which are expected to provide around 80 bits of security strength are…

I don't like the "and any other cryptographic algorithms which are
expected to provide around 80 bits of security"

First, it is not very helpful to people who don't know which algorithms
are expected to provide 80 bits of security. And second, I guess the 80
bits is a NIST / USG specific value, not a cryptographic community
standard.

Paul

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Thu, 12 May 2016 14:14:59 +0000

Hi Paul,

80 bits of security strength is the bigiest number that I have seen from the cryptographic community for estimating the strength  of  1k DH.

Regards,
Quynh.
________________________________________
From: IPsec <[email-masked]> on behalf of Paul Wouters <[email-masked]>
Sent: Thursday, May 12, 2016 9:46:58 AM
To: Dang, Quynh (Fed)
Cc: IPsecME WG; Tero Kivinen
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 13 May 2016 11:45:39 +0300

Dang, Quynh (Fed) writes:
> 80 bits of security strength is the bigiest number that I have seen
> from the cryptographic community for estimating the strength  of  1k
> DH. 

That might be so, but there is still quite a lot of different
estimates for the equivalent strengts between symmetric and asymmetric
keys. 

Saying that anything below 80 bits security strength is weak does not
mean anything unless we also defined what is the security strength for
each algorithm, and we do not want to do it here.

Also that statement would not cover group 5 which is considered having
more strength than group 2, but how much is open to debate.

We already say that:

   Group 2 or 1024-bit MODP Group has been downgraded from MUST- in
   RFC4307 to SHOULD NOT.  It is known to be weak against sufficiently
   funded attackers using commercially available mass-computing
   resources, so its security margin is considered too narrow.  It is
   expected in the near future to be downgraded to MUST NOT.

If the reader still wants to use it, he needs to have good reasons why
and he then himself takes that risk of using it.

For group 5 we say:

   Group 5 or 1536-bit MODP Group has been downgraded from MAY in
   RFC4307 to SHOULD NOT.  It was specified earlier, but is now
   considered to be vulnerable to be broken within the next few years by
   a nation state level attack, so its security margin is considered too
   narrow.

I still think both of those comments are accurate, and suitable for
this document.
-- 
[email-masked]

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Fri, 13 May 2016 10:21:46 +0000

Hi Tero,

That was why I said "around" when talking about security strength.

Again, I like your proposed text  change!

Regards,
Quynh.
Sent: Friday, May 13, 2016 4:45:39 AM

We already say that:

For group 5 we say: