Subject: [IPsec] RFC4307 update

From: Tero Kivinen <[email-masked]>
Date: Mon, 28 Sep 2015 16:11:04 +0300

We did update cryptographic algorithms for ESP and AH
(RFC4305->4835->7321), but we have never updated the RFC4307.

I think there should be update for that document too, as it now
defines following madantory to implement algorithms:

1024 MODP Group, ENCR_3DES, PRF_HMAC_SHA1, AUTH_HMAC_SHA1_96.

And I think at least the 1024-bit MODP groupp, and perhaps the 3DES
also should be changed to something more suitable. For exmple 2048-bit
MODP group and ENCR_AES_CBC...

We had this discussion about two years ago last time, but nothing came
out from there (Hmm.. did I promise to do something, I hope not).

Perhaps this time? 

https://www.ietf.org/mail-archive/web/ipsec/current/msg08597.html
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Mon, 28 Sep 2015 10:19:19 -0400 (EDT)

> Perhaps this time?

It is. especially 2048 modp would be good, as most IKEv2 implementations
already try that as their default group. Demoting 3des/m5/sha1 and
pulling in aes_gcm and sha2 would be good I think.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Mon, 28 Sep 2015 17:38:20 +0300

> On Sep 28, 2015, at 4:11 PM, Tero Kivinen <[email-masked]> wrote:
> 

Totally yes.

      Group Number        Bit Length            Status     Defined
      2                   1024 MODP Group       MUST-      [RFC2409]

   MUST-      This term means the same as MUST.  However, we expect at
              some point that this algorithm will no longer be a MUST in
              a future document.  Although its status will be determined
              at a later time, it is reasonable to expect that if a
              future revision of a document alters the status of a MUST-
              algorithm, it will remain at least a SHOULD or a SHOULD-.

“Some point” has arrived, and I don’t think group #2 should even be SHOULD- at this point.

So what should we specify now?  My opinion:

DH Groups
   14: MUST
   19: SHOULD+

Type 1 algorithms:
   ENCR_AES_CBC: MUST-
   AES-GCM with 16 octet ICV: MUST
   ENCR_CHACHA20_POLY1305: SHOULD+
   
Type 2 algorithm:
   PRF_HMAC_SHA1: MUST-
   PRF_HMAC_SHA2_256: MUST
   PRF_HMAC_SHA2_512: SHOULD+
   
Type 3 algorithm:
   AUTH_HMAC_SHA1_96: MUST-
   AUTH_HMAC_SHA2_256_128: MUST
   AUTH_HMAC_SHA2_512_256: SHOULD+  (or maybe AUTH_AES_256_GMAC??)

Yoav

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 28 Sep 2015 08:10:15 -0700

Sure. Someone volunteer to write up the short draft, and that author 
should put Jeff Schiller at the top of the acknowledgements, and send it 
to the WG.

--Paul Hoffman

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Sep 2015 11:57:08 -0400

> I think there should be update for that document too, as it now defines
    > following madantory to implement algorithms:

    > MODP group and ENCR_AES_CBC...

I guess the can-o-worms called ECDSA will show up too as a SHOULD+.
Does 3DES go to MAY?
Does SHA1 go to MUST-?

We hadn't listed SHA2 at all before.
We also have no GCM/CCM things specified.

Are we obligted to list them as SHOULD+ for awhile?

I think that the updates will otherwise be non-controversial.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Yoav Nir <[email-masked]>
Date: Mon, 28 Sep 2015 20:34:28 +0300

> On Sep 28, 2015, at 6:57 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

Does it have to? 4307 does not mention any signature algorithms. ECDH with NIST curves and/or the new curves might should make an appearance.

> Does 3DES go to MAY?

I think so.

> Are we obligted to list them as SHOULD+ for awhile?

I think we should reflect what is common/best practice now. AES-GCM is now widely implemented and faster than the combination of AES-CBC and HMAC-SHA-something. I think it’s a prime candidate for MUST. CTR was always uncommon. ChaCha20+Poly1305 is so new that it can't be MUST this iteration. Maybe next time.

> I think that the updates will otherwise be non-controversial.

Maybe.

Yoav

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Sep 2015 15:39:28 -0400

> “Some point” has arrived, and I don’t think group #2 should even be

MAY or SHOULD NOT?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Sep 2015 15:40:48 -0400

Yoav Nir <[email-masked]> wrote:
    >>> also should be changed to something more suitable. For exmple
    >>> 2048-bit MODP group and ENCR_AES_CBC...
    >>

    > Does it have to? 4307 does not mention any signature algorithms. ECDH
    > with NIST curves and/or the new curves might should make an appearance.

Sorry, that's what I meant to write, but my finger slipped.

    >> Does SHA1 go to MUST-?
    >>
    >> We hadn't listed SHA2 at all before.  We also have no GCM/CCM things
    >> specified.
    >>

    > I think we should reflect what is common/best practice now. AES-GCM is
    > now widely implemented and faster than the combination of AES-CBC and
    > HMAC-SHA-something. I think it’s a prime candidate for MUST. CTR was
    > always uncommon. ChaCha20+Poly1305 is so new that it can't be MUST this
    > iteration. Maybe next time.

Agreed.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 28 Sep 2015 23:42:31 +0300

> On Sep 28, 2015, at 10:39 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

I’m thinking SHOULD NOT. Everyone phased out 1024-bit RSA signatures a few years ago. It can be argued that 1024-bit key agreement is worse than 1024-bit signatures, because if the attacker will be able to crack 1024-bit RSA or DH in 2018, then they can break any IKE that they recorded today that uses the 1024-bit MODP group. OTOH knowing how to break 1024-bit RSA in 2018 doesn’t help them impersonate anyone today, so a safety margin seems more important for D-H than for signatures.

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 29 Sep 2015 12:15:18 +0300

Yoav Nir writes:
> I think we should reflect what is common/best practice now. AES-GCM
> is now widely implemented and faster than the combination of AES-CBC
> and HMAC-SHA-something.

Remember that we are talking about the IKEv2 SA now, not ESP, or AH.

The main reason for AES-GCM is the speed, and that that you do not
need to implement HMAC based MAC. In the IKEv2 those arguments are not
very valid. We do not really encrypt that much data in IKEv2 SA that
speed would matter. Also we always need to have some PRF to extract
the keying material from the DH output.

On the other hand I have seen some questions about the suitability of
the CMAC as PRFs to extract keying material (i.e as KDF). Not sure
whether XCBC is any better.

https://www.ietf.org/mail-archive/web/cfrg/current/msg02693.html

Because of this it might be that we want to keep one HMAC based PRF as
mandatory to implement anyways, thus using same HMAC for
authentication does not add any code. 

> I think it’s a prime candidate for MUST. CTR was always uncommon.

The small IoT devices would most likely want to use AES-CCM based
systems, mostly because they might already have that on the hardware.

> ChaCha20+Poly1305 is so new that it can't be MUST this iteration.
> Maybe next time.

Yep. 

> > I think that the updates will otherwise be non-controversial.

So my take would be:

DH group 2 1024-bit MODP 	MUST- -> MAY
DH group 14 2048-bit MODP	SHOULD+ -> MUST

Not sure which elliptic curves to propose. The NIST groups 19-21 has
the problem that there has been two complient ways to implement them
and those two ways are not interoperable, thus they would be bad idea
for mandatory to implement algorithm (i.e. they do not guarantee
interoperability). Brainpool curves are not that widely implemented,
and the cfrg is now working on adding another groups. Perhaps we can
add those new groups as SHOULD+ in the next iteration and leave this
draft as MODP only for now.

IKEv2 Transform Type 1 Algorithms

ENCR_DES			MAY -> MUST NOT
ENCR_3DES			MUST-  -> MAY
ENCR_AES_CBC            	SHOULD+ -> MUST 
ENCR_AES_CTR            	SHOULD -> MAY
ENCR_CHACHA20_POLY1305		MAY -> SHOULD+

We could also add 

ENCR_AES_CCM_8			MAY -> SHOULD
AES-GCM with a 8 octet ICV	MAY -> SHOULD

but as this is IKEv2 SA we are talking about, we can just leave them
out, and say we have AES as primary algorithm and CHACHA20_POLY1305 as
backup. 

IKEv2 Transform Type 2 Algorithms

PRF_HMAC_MD5        MAY -> MAY
PRF_HMAC_SHA1       MUST -> MUST-
PRF_AES128_CBC      SHOULD+ -> SHOULD
PRF_HMAC_SHA2_256   MAY -> SHOULD+

IKEv2 Transform Type 3 Algorithms

AUTH_HMAC_MD5_96         MAY -> MAY
AUTH_HMAC_SHA1_96        MUST -> MUST-
AUTH_AES_XCBC_96         SHOULD+ -> SHOULD
AUTH_HMAC_SHA2_256_128	 MAY -> SHOULD+
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Tue, 29 Sep 2015 14:09:52 +0300

> On Sep 29, 2015, at 12:15 PM, Tero Kivinen <[email-masked]> wrote:
> 
> Yoav Nir writes:
>>> Does SHA1 go to MUST-?
>>> 
> speed would matter.

This makes sense. AES-GCM is defined for IKE in RFC 5282, but if you need to encrypt so much in IKE that AES-CBC + HMAC-SHA-something is not fast enough, you’re doing it wrong regardless of how weak your processor is. 

> Also we always need to have some PRF to extract

I have thought about that a bit. The way the KDF is defined in IKEv2 limits us to functions that play well with PRF+. I’m thinking that we should extend or update IKE to be able to work with other KDFs such as HKDF or SHAKE128 or Blake2 or just some some natural PRF based on ChaCha20.  But that is not for *this* iteration of 4307 even if we started working on that tomorrow.

> interoperability).

Is that still an issue? I thought this was a bug some years ago that everyone had fixed, no?

> Brainpool curves are not that widely implemented,

I don’t have a survey of implementations, but I think 19,20, and 21 and more widely implemented than groups 15-18. So if somebody gets uncomfortable with 2048 bits (see [1]) it’s better to recommend that people move to an EC curve. I’d rather this be done with something that’s well established rather than something that is in a -00 draft submitted this month, but we should find out if interop works right now.

Yoav

[1] https://mailarchive.ietf.org/arch/msg/tls/Mul0etdAxsFtpdJeBX2R-enGNN8

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 29 Sep 2015 15:23:59 +0300

> Is that still an issue? I thought this was a bug some years ago that

It was not really a bug. We defined ECP differently than everybody
else in the RFC, and then there was errata made that completely
changed the format (errata did not change the test vectors or
examples). Some implementations implemented what was written in RFC,
some implemented what was written in errata. Then when this was
noticed, we fixed the RFC by writing a new one, but authors wanted to
keep the old group numbers, which caused the problem that now we do
not know whether implementation supports this new RFC, or the old RFC
without errata. And those two versions do not interoperate.

If we would be in perfect world where we would know that everybody
uses latest versions of software, which implements latest version of
rfcs, then we could ignore this. As there are still lot of people
using IKEv1 which was obsoleted long ago, I assume there is still
people out there using old version of ECP too.

And of course there are people who are against NIST curves just in
general... 

> I don’t have a survey of implementations, but I think 19,20, and 21
> and more widely implemented than groups 15-18. So if somebody gets
> uncomfortable with 2048 bits (see [1]) it’s better to recommend that
> people move to an EC curve. I’d rather this be done with something
> that’s well established rather than something that is in a -00 draft
> submitted this month, but we should find out if interop works right
> now.

If people are already implementing 19-21 then there is no problem. We
do not need to specify them as MUST or SHOULD or SHOULD+, and people
can still use them if they feel like it.

I think that when CFRG and IPsecME WG get Curve25519 etc work done, we
are going to make that one as second mandatory to implement curve,
i.e. then making group 19 as SHOULD- or something like that now, would
not be that useful.
-- 
[email-masked]