[IPsec] Comments to the draft-ietf-ipsecme-rfc4307bis-03

["Tero Kivinen <"<[e-mail]>]

Here are some comments for the algorithms and some nits we should fix.

> 1.1.  Updating Algorithm Implementation Requirements and Usage Guidance
> 
>    The field of cryptography evolves continiously.  New stronger
     	       	  	       	       ^^^^^^^^^^^^

Typo.

> 2.  Conventions Used in This Document
...
>    SHOULD-   This term means the same as SHOULD.  However, an algorithm
>              marked as SHOULD- may be deprecated to a MAY in a future
>              version of this document.

I think we should also mention that it may be deprectated to SHOULD
NOT or even MUST NOT in addition to MAY. For example I think SHA-1
might be in that class for now. We need to keep it as SHOULD as it is
so widely implemented and is needed for backwards compability, but
when it is no longer needed then it will move to SHOULD NOT, or MUST
NOT.

> 3.1.  Type 1 - IKEv2 Encryption Algorithm Transforms
...
>        +-----------------------------+----------+-------+----------+
>        | Name                        | Status   | AEAD? | Comment  |
>        +-----------------------------+----------+-------+----------+
>        | ENCR_AES_CBC                | MUST-    | No    | [1]      |
>        | ENCR_CHACHA20_POLY1305      | SHOULD   | Yes   |          |
>        | AES-GCM with a 16 octet ICV | SHOULD   | Yes   | [1]      |
>        | ENCR_AES_CCM_8              | SHOULD   | Yes   | [1][IoT] |
>        | ENCR_3DES                   | MAY      | No    |          |
>        | ENCR_DES                    | MUST NOT | No    |          |
>        +-----------------------------+----------+-------+----------+

I think the table itself is ok, i.e., this is how we want to specify
them. 

>    AES-GCM with a 16 octet ICV was not considered as in RFC4307.  At the
>    time RFC4307 was written, AES-GCM was not defined in an IETF
>    document.  AES-GCM was defined for ESP in [RFC4106] and later for
>    IKEv2 in [RFC5282].  The main motivation for adopting AES-GCM for ESP
>    is encryption performance as well as key longevity - compared to AES-
>    CBC for example.  This resulted in AES-GCM widely implemented for
>    ESP.  As the load of IKEv2 is expected to remain relatively small,
>    many IKEv2 implementations do not include AES-GCM.  In addition to
>    its former MAY, this document does not promote AES-GCM to a greater
>    status than SHOULD so to preserve interoperability between IKEv2
>    implementations.

Up to here this is ok. 

> [PAUL: I dont follow the reasoning, as we could
>    have AES and AES-GCM at MUST level] This document considers AES-GCM
>    as mandatory to implement to promote the slightly more secure AEAD
>    method over the traditional encrypt+auth method.  Its status is
>    expected to be raised once widely deployed.

This text is leftover, and should be removed, as it is now for SHOULD,
not SHOULD+ or MUST.

Also I think the ENCR_CHACHA20_POLY1305 is most likely going to be the
next MUST to implement algorithm, in the next iteration of this
document, if implementations actually start implementing and deploying
it. 

>    ENCR_3DES has been downgraded from RFC4307 MUST-. All IKEv2
>    implementation already implement ENCR_AES_CBC, so there is no need to
>    keep ENCR_3DES.  In addition, ENCR_CHACHA20_POLY1305 provides a more
>    modern alternative to AES.  [PAUL: removed 'efficient' as we said
>    above encryption efficiency at the IKE level hardly matters]

Remove 'PAUL:' comment.

> 3.2.  Type 2 - IKEv2 Pseudo-random Function Transforms
...
>                  +-------------------+---------+---------+
>                  | Name              | Status  | Comment |
>                  +-------------------+---------+---------+
>                  | PRF_HMAC_SHA2_256 | MUST    |         |
>                  | PRF_HMAC_SHA2_512 | SHOULD+ |         |
>                  | PRF_HMAC_SHA1     | MUST-   | [1]     |
>                  | PRF_AES128_CBC    | SHOULD  | [IoT]   |
>                  +-------------------+---------+---------+

Again the table is mostly ok. We need to keep PRF_HMAC_SHA1 as MUST-,
as it is the most widely implemented and deployed algorithm. In next
version we will move it to lower level.

On the other hand we should add other PRFs to the MUST NOT, i.e. say
that PRF_HMAC_MD5 is MUST NOT, and perhaps say that PRF_HMAC_TIGER is
SHOULD NOT. 

> 3.3.  Type 3 - IKEv2 Integrity Algorithm Transforms
> 
>    The algorithms in the below table are negotiated in the SA payload
>    and used in the ENCR payload.  References to the specifications
     	      	     ^^^^

Replace this with Encrypted Payload, just like it is in section 3.1.

>                +------------------------+--------+---------+
>                | Name                   | Status | Comment |
>                +------------------------+--------+---------+
>                | AUTH_HMAC_SHA2_256_128 | MUST   |         |
>                | AUTH_HMAC_SHA2_512_256 | SHOULD |         |
>                | AUTH_HMAC_SHA1_96      | SHOULD |         |
>                | AUTH_AES_XCBC_96       | SHOULD | [IoT]   |
>                +------------------------+--------+---------+

This is not aligned with the PRF section, where we had PRF_HMAC_SHA1
as MUST-, and here we have it as SHOULD. As both are used in the same
way, I think we should have MUST- here too. I do not think the
AUTH_HMAC_SHA2_256_128 has wide enough imployment base yet to make it
only MUST algorithm.

Also we might want to add that AUTH_HMAC_MD5_96, AUTH_DES_MAC,
AUTH_KPDK_MD5 are MUST NOT.

Also perhaps point out that AUTH_MHAC_MD5_128, and AUTH_HMAC_SHA1_160,
are not for IKE use and are MUST NOT for IKEv2.

>    AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC4307.  There is
>    an industry-wide trend to deprecate its usage.

I think MUST- would be better than SHOULD. 

> 3.4.  Type 4 - IKEv2 Diffie-Hellman Group Transforms

I think we should add note here saying that attacks against
Diffie-Hellman groups are different than against the RSA and other
authentication algorithms. To break Diffie-Hellman few years later
will provide attacker the information what was transmitted over the
IPsec link. To break RSA or DSS used for the authentication will need
active attack to fake authentication to gain same effect. Breaking RSA
or other authentication algorithms few years later when it is no
longer in use does not provide anything.

Because of this you need to use greated security margin for the
Diffie-Hellman than what you need to do for authentication. This text
should either be here, or in the beginning of the section 4 (or in
both places). 

>    +--------+----------------------------------------------+-----------+
>    | Number | Description                                  | Status    |
>    +--------+----------------------------------------------+-----------+
>    | 14     | 2048-bit MODP Group                          | MUST      |
>    | 19     | 256-bit random ECP group                     | SHOULD    |
>    | 5      | 1536-bit MODP Group                          | SHOULD    |
>    |        |                                              | NOT       |
>    | 2      | 1024-bit MODP Group                          | SHOULD    |
>    |        |                                              | NOT       |
>    | 1      | 768-bit MODP Group                           | MUST NOT  |
>    | 22     | 1024-bit MODP Group with 160-bit Prime Order | MUST NOT  |
>    |        | Subgroup                                     |           |
>    | 23     | 1024-bit MODP Group with 224-bit Prime Order | MUST NOT  |
>    |        | Subgroup                                     |           |
>    | 24     | 1024-bit MODP Group with 256-bit Prime Order | MUST NOT  |
>    |        | Subgroup                                     |           |
>    +--------+----------------------------------------------+-----------+

This table is hard to read as SHOULD NOT is split over two lines, It
would be better to make this more readable and ensure that SHOULD
stays on one line...

I do not agree on making groups 22-24 as MUST NOT. I think SHOULD NOT
would be better for them than MUST NOT. Provided that you do all the
checks specified in the RFC6989 I think they are still secure.

>    Group 14 or 2048-bit MODP Group is raised from SHOULD+ in RFC4307 as
>    a replacement for 1024-bit MODP Group.  Group 14 is widely
>    implemented and considered secure

Period missing from the end.

>    Group 19 or 256-bit random ECP group was not specified in RFC4307.
>    Group 19 is widely implemented and considered secure

Period missing from the end.

>    Group 5 or 1536-bit MODP Group is downgrade from MUST- to SHOULD NOT.
>    It was specified earlier, but 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.

This is untrue. Group 5 was NOT mentioned in the RFC4307, i.e., it was
not MUST-. Correct text would say that "Group 5 or 1536-bit MODP Group
was not specified in the RFC4307, but is now considered to be
vulnerable to be broken within then next few years by a nation state
level attack, so its security margin is considered too narrow".

>    Group 2 or 1024-bit MODP Group is downgrade from MUST- to SHOULD NOT.
>    It was specified earlier, but now 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.

This text is ok. 

>    Group 1 or 768-bit MODP Group can be broken within hours using cheap
>    of-the-shelves hardware.  It provides no security whatsoever.

As is this.

>    Curve25519 has been designed with performance and security in mind
>    and have been recommended by CFRG.  At the time of writing, the IKEv2
>    specification is still at the draft status.  This document specifies
>    it as to encourage its implementation and deployment.  If it gets
>    widely implemented then it most likely will be upgraded to SHOULD or
>    even MUST in the future.

As we do not have Curve25519 listed in the table, we should have text
for it either. Remove this text.

And yes, when it gets specified, and gets implemented it might change
to SHOULD or MUST... 

>    Group 22-24 or 1024-bit MODP Group with 160-bit and 2048-bit MODP
>    Group with 224-256-bit Prime Order Subgroup are exposed to
>    synchronization or transcription attacks.

This is not really true. To be exposed to the synchronization or
transcription attacks it requires the implementations to use broken
authentication hash (MD5), and/or use static SPIi and SPIr, and NOT to
implement checks listed in the RFC6989.

It is ok to say they are SHOULD NOT, as they are slower than other
groups, as there is extra modexp to be done to check against small
subgroup attack.

We should also provide reference to the RFC6989 and say that checks
specified in the section 2.2 first bullet MUST be done. 

> 4.  IKEv2 Authentication
> 
>    IKEv2 authentication may involve a signatures verification.
>    Signatures may be used to validate a certificate or to check the
>    signature of the AUTH value.  Cryptographic recommendations regarding
>    certificate validation are out of scope of this document as what
>    mandatory implementations are provided by the PKIX WG.  This document
     	       		       	   	       	   ^^^^^^^

That WG does not exist anymore, so change that to say PKIX community. 

>    is mostly concerned on signature verification and generation for the
>    authentication.

Here we could add text explaining that braking signature
authentication requires breaking it while it is still in use, breaking
it few years later does not help, thus security levels are different
than with the Diffie-Hellman.

Also we should point out RFC4307 did not give any guidance for them. 

> 4.1.  IKEv2 Authentication Method
> 
>    +--------+-------------------------+--------+-----------------------+
>    | Number | Description             | Status | Comment               |
>    +--------+-------------------------+--------+-----------------------+
>    | 1      | RSA Digital Signature   | MUST   | With keys length 2048 |
>    | 1      | RSA Digital Signature   | SHOULD | With keys length      |
>    |        |                         |        | 3072/4096             |
>    | 1      | RSA Digital Signature   | MUST   | With keys length      |
>    |        |                         | NOT    | lower than 2048       |
>    | 3      | DSS Digital Signature   | MAY    |                       |
>    | 9      | ECDSA with SHA-256 on   | SHOULD |                       |
>    |        | the P-256 curve         |        |                       |
>    | 10     | ECDSA with SHA-384 on   | SHOULD |                       |
>    |        | the P-384 curve         |        |                       |
>    | 11     | ECDSA with SHA-512 on   | SHOULD |                       |
>    |        | the P-521 curve         |        |                       |
>    | 14     | Digital Signature       | SHOULD |                       |
>    +--------+-------------------------+--------+-----------------------+

I do not agree on MUST NOT for RSA with lower than 2048 bit keys.
First of all 2047 bit keys are about same than 2048. Also breaking RSA
requires dedicated attack against that specific user. The 1024 bit
Diffie-Hellman attacks were based on that everybody uses same group,
thus nation wide bodies can do precalcuation for that group and gain
speedup for that. For RSA everybody is using different key, thus I do
not think there is such issues.

I think it would be safe to say that 1024 bit RSA is SHOULD NOT, and
anything lower than 1000 bit is MUST NOT, but where the limit goes
between SHOULD NOT and MAY is different thing.

Perhaps something like:

  < 1000 bits	  MUST NOT
  < 1500 bits	  SHOULD NOT
  < 2000 bits	  MAY
  < 2500 bits	  MUST
  < 5000 bits	  SHOULD

And the whole RSA Digital Signatures method is MUST-.

I.e. split this table in two, first one saying:

    +--------+-------------------------+-----------+
    | Number | Description             | Status    |
    +--------+-------------------------+-----------+
    | 1      | RSA Digital Signature   | MUST-     |
    | 3      | DSS Digital Signature   | MUST NOT  |
    | 9      | ECDSA with SHA-256 on   | SHOULD    |
    |        | the P-256 curve         |           |
    | 10     | ECDSA with SHA-384 on   | SHOULD    |
    |        | the P-384 curve         |           |
    | 11     | ECDSA with SHA-512 on   | SHOULD    |
    |        | the P-521 curve         |           |
    | 14     | Digital Signature       | SHOULD+   |
    +--------+-------------------------+-----------+

and then have another section to specify the RSA key lengths, which is
used for both RSA Digital Signature, and Digital Signature using RSA. 

>    RSA Digital Signature is mostly kept for interoperability.  It is
>    expected to be downgraded in the future as signatures are based on
>    RSASSA-PKCS1-v1.5, not any more recommemded.  Instead, more robust
>    use of RSA is expected to be performed via the Digital Signature
>    method.

This is good. 

>    ECDSA family are also expected to be downgraded as it does not
>    provide hash function agility.  Instead ECDSA is expected to be
>    performed using the generic Digital Signature method.

If we are expecting them to be downgraded, why are we listing them as
SHOULD, and not SHOULD-? Or why are we actually listing them at all.
Perhaps it would be better to say that for ECDSA the recommended
method is to do RFC7427 support.

>    DSS Digital Signature is bound to SHA-1 and thus is expected to be
>    downgraded to MUST NOT in the future.

I think we should deprecate it to MUST NOT already now. Or at least
mark it as SHOULD NOT...


>    Digital Signature is expected to be promoted as it provides hash
>    function, signature format and algorithm agility.

Add reference to the RFC7427 here. 

>    [MGLT: Do we have any recommendation for the authentication based on
>    PSK?]

I do not think we want to say anything about that, so we can remove
this comment. 

> 4.2.  Digital Signature Recommendation
> 
>    Here are the recommendations for the authentication methods.

Add here text saying that this section only covers RFC7427.

>    +--------+-------------+----------+---------------------------------+
>    | Number | Description | Status   | Comment                         |
>    +--------+-------------+----------+---------------------------------+
>    | OID    | RSA         | MUST     | With keys length 2048           |
>    | OID    | RSA         | SHOULD   | With keys length 3072/4096      |
>    | OID    | RSA         | MUST NOT | With keys length lower than     |
>    |        |             |          | 2048                            |
>    | OID    | ECDSA       | SHOULD   |                                 |
>    +--------+-------------+----------+---------------------------------+

Again remove the key lengths, and list the actual oid names, i.e. say
that PKCS#1 1.5 RSA is now SHOULD as it allows easy transtion from the
RSA Digital signatures using PKCS#1 1.5 RSA to Digital Signature
(RFC7427) method. I.e.

   sha1WithRSAEncryption	SHOULD NOT
   sha256WithRSAEncryption	MAY

all others are MAY.

For the DSA:

   dsa-with-sha1		SHOULD NOT
   dsa-with-sha256		MAY

For ECDSA

   ecdsa-with-sha1		SHOULD NOT
   ecdsa-with-sha256		MAY
   ecdsa-with-sha384		MAY
   ecdsa-with-sha512		MAY

And for RSASSA-PSS:

   id-RSASSA-PSS		MUST

I.e. the final table will be like:

   +--------------------------+----------------+-------------+
   | OID		      | Algorithm      | Status      |
   +--------------------------+----------------+-------------+
   | sha1WithRSAEncryption    | PKCS#1 1.5 RSA | SHOULD NOT  |
   | sha256WithRSAEncryption  | PKCS#1 1.5 RSA | MAY         |
   | dsa-with-sha1	      | DSA            | SHOULD NOT  |
   | dsa-with-sha256          | DSA            | MAY	     |
   | ecdsa-with-sha1  	      | ECDSA          | SHOULD NOT  |
   | ecdsa-with-sha256 	      | ECDSA	       | MAY   	     |
   | ecdsa-with-sha384        | ECDSA	       | MAY	     |
   | ecdsa-with-sha512 	      | ECDSA	       | MAY	     |
   | id-RSASSA-PSS 	      | RSASSA-PSS     | MUST        |
   +--------------------------+----------------+-------------+

And then have the hash function table still as separate:

>    Here are the recommendations when a hash function is involved in a
>    signature.
> 
>                 +--------+-------------+--------+---------+
>                 | Number | Description | Status | Comment |
>                 +--------+-------------+--------+---------+
>                 | 1      | SHA1        | MUST   |         |
>                 | 2      | SHA2-256    | MUST   |         |
>                 | 3      | SHA2-384    | MAY    |         |
>                 | 4      | SHA2-512    | SHOULD |         |
>                 +--------+-------------+--------+---------+

And here I think SHA1 should be SHOULD NOT, and others as they are in
table. 

>    With the use of Digital Signature, RSASSA-PKCS1-v1.5 MAY be
>    implemented, and RSASSA-PSS MUST be implemented.

As we already have the OID table specifying this, I do not think we
need this text here, but we might again explain bit of the reasons.

I.e. sha1WithRSAEncryption, dsa-with-sha1 and ecdsa-with-sha1 are
all SHOULD NOTs as they use SHA-1 which is SHOULD NOT to be used as
hash algorithm. The sha256WithRSAEncryption is MAY as PKCS#1 1.5 based
RSA would be better to be replaced with RSASSA-PSS based RSA, but they
are allowed as they provide easy transition from the old RSA Digital
signatures to Digital signatures.

> 5.  Security Considerations
... 
>    The Diffie-Hellman Groups parameter is the most important one to
>    choose conservatively.  Any party capturing all traffic that can
>    break the selected DH group can retroactively gain access to the
>    symmetric keys used to encrypt all the IPsec data.  However,
>    specifying extremely large DH group also puts a considerable load on
>    the device, especially when this is a large VPN gateway or an IoT
>    constrained device.

Ok, we already have this text here, so it might not need to be in the
3.4, but adding some text on the beginning of section 4 might still be
needed. 
-- 
[e-mail]