Subject: [IPsec] Update to RFC4307 too?

From: Tero Kivinen <[email-masked]>
Date: Wed, 9 Oct 2013 19:14:38 +0300

While we are updating the algorithm requirements for the ESP and AH, I
think we should also update the RFC4307 too at the same time, as a
separate document.

I think the changes we would like to do there are:

Downgrade Diffie-Hellman group 2 (1024-bits) from MUST- to SHOULD.
Upgrade Diffie-Hellman group 14 (2048-bits) from SHOULD+ to MUST.
Downgrade ENCR_3DES from MUST- to MAY
Fix ENCR_NULL from MAY to MUST NOT (already MUST NOT in errata)
Upgrade ENCR_AES_CBC from SHOULD+ to MUST
Fix PRF_AES128_CBC to PRF_AES128_XCBC and downgrade it from SHOULD+ to SHOULD.
Downgrade AUTH_AES_XCBC_96 from SHOULD+ to SHOULD.

Then we might want to think whether we want to add new algorithms,
i.e. "AES_GCM with a 8/12/16 octect ICV", PRF_HMAC_SHA2_256/384/512,
or AUTH_HMAC_SHA2_256_128/384_192/512_256. In all of those I think we
might want to pick one length and make that SHOULD...
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Fri, 11 Oct 2013 14:48:57 -0400 (EDT)

> Downgrade Diffie-Hellman group 2 (1024-bits) from MUST- to SHOULD.

Actually, 4307 states:

3.1.2.  Diffie-Hellman Groups

    There are several Modular Exponential (MODP) groups that are defined
    for use in IKEv2.  They are defined in both the [IKEv2] base document
    and in the MODP extensions document.  They are identified by group
    number.  Any groups not listed here are considered as "MAY be
    implemented".

       Group Number        Bit Length            Status     Defined
       2                   1024 MODP Group       MUST-      [RFC2409]
       14                  2048 MODP Group       SHOULD+    [RFC3526]

which seems to imply 768 MODP group is "MAY". Which is confirmed in RFC
4109. So I think we should also update 768 MODP group to MUST NOT.

> Downgrade ENCR_3DES from MUST- to MAY

I'm not sure how I feel about that. There are still not many
alternatives to AES, and I think having 3DES in there is good. Yes it is
slow, but I don't think it has been concluded to be weak or insecure.

> might want to pick one length and make that SHOULD...

Sounds good.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 14 Oct 2013 15:55:43 +0300

> 4109. So I think we should also update 768 MODP group to MUST NOT.

I agree on that. I thought we deprecated that already in the RFC4306
by saying:

----------------------------------------------------------------------
Appendix B: Diffie-Hellman Groups
...
   The strength supplied by group one may not be sufficient for the
   mandatory-to-implement encryption algorithm and is here for historic
   reasons.
...
----------------------------------------------------------------------

but it might be better to say MUST NOT explictly.

> slow, but I don't think it has been concluded to be weak or insecure.

I think we need to downgrade it from MUST to something else anyways,
as small implementations which do have hardware support for AES, might
not want to add implementation for 3DES at all.

You can still implement and use it, it just would not be mandatory to
implement algorithm anymore. I.e. if you need to pick one algoritm I
think AES is better than 3DES. If you want to implement 2 algorithms
then implementing both AES and 3DES is ok. We could also make it
SHOULD- instead of MAY, but I think MAY is still better.

Note to others: the main problem with 3DES (i.e. the too long block
length) is not relevant here as we are talking about the encryption
algorithm protecting key management messages, where the number of
actual bytes transmitted are going to be quite low compared to the
block length restrictions from 3DES. There is mandatory requirement to
rekey after 2^32 IKEv2 messages has been transmitted anyways, but in
general the amount of messages transmitted is between 2 -- 10000. 
-- 
[email-masked]