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

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Mar 2016 13:03:31 -0400 (EDT)

On Wed, 16 Mar 2016, [email-masked] wrote:

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

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

This version introduces an RSA key size table and a Digitial Signature
OID table. It changed some requirement levels in the existing tables
and added some missing entries (eg PRF_HMAC_MD5). It also has extended
text for the MODP group justifications.

Please read carefully and give the authors feedback. We have read many
interim versions between ourselves, so we are likely missing some
obvious mistakes now :)

Paul

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 17 Mar 2016 08:16:12 -0400

<chair hat on>

This version has many significant changes from the previous draft. 
Please review it soon so we don't have a lot of surprises in WG Last 
Call.

--Paul Hoffman

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 22 Mar 2016 17:32:21 +0300

Hi,

> Please review it soon so we don't have a lot of surprises in WG Last 

here is my review of the draft. 

Most issues are editorial. In a few places text needs to be improved,
Section 4.1. needs more explanation text. Otherwise the document looks good.

1. No period at the end of Abstract.

2. Section 1.

   The IKE protocol itself is
   also protected by encryption which is negotiated between the two
   endpoints using IKE.

    This text is not accurate, since it doesn't mention authentication (MAC),
    that also protects IKE SA.

3. Section 1.

    In the text

   To
   ensure interoperability, a set of "mandatory-to-implement" IKE
   encryption algorithms is defined.

    s/encryption algorithms/cryptographic algorithms

4. Section 1.1

   The algorithm implementation requirements and usage guidance may need
   to change over time to adapt to the changing world.  For this reason,
   the selection of mandatory-to-implement algorithms was removed from
   the main IKEv2 specification and placed in this document.

    Isn't it better to change:

    s/in this document/in a separate document

    (because the guidelines were not only in _this_ document, but also in previous documents)
    
5. Section 3.1

   The algorithms in the below table are negotiated in the SA payload
   and used for the Encrypted Payload.  

    Isn't "in the table below" more grammatically correct? The same in Section 3.3.

6. Section 3.1

       AES-GCM with a 16 octet ICV was not considered as in RFC4307.

    Shouldn't "as" be removed from grammar point of view?

7. Descriptions for AES-GCM and ENCR_AES_CCM_8 demonstrate some
    inconsistency. While the former claims that the advantage of using
    shorter than 16 bytes ICV are minimal, the latter claims that 
    8 bytes ICV is enough for IKE SA. Sure, the latter is for IoT use case,
    but I don't expect that the amount of data transferred over IKE SA
    in IoT and non-IoT cases is many magnitudes different.
    I think some other reasons must be given to justify this selection.
    For example: the majority of existing IoT devices implement
    ENCR_AES_CCM_8, so we decided to make it mandatory in IKE
    (well, I don't know if it is true, I'm not familiar with IoT world).

8. Section 3.2

   Transform Type 2 Algorithms are pseudo-random functions used to
   generate random values when needed.

    s/Algorithms/algorithms
    s/random/pseudorandom

9. Section 3.2

   If an algorithm is selected as the integrity algorithm, it SHOULD
   also be used as the PRF.  When using an AEAD cipher, a choice of PRF
   needs to be made.

    This text is not clear for me. What do you mean? The PRF needs always
    be negotiated in IKEv2, regardless of AEAD/non-AEAD cipher.
    Or do you mean that when non-AEAD cipher is used then
    PRF and ICV transforms SHOULD be based on the same underlying algorithm?
    Is it justified somewhere? Well, I can imagine some reasons for it, but I don't
    like uppervase "SHOULD" here unless you provide some reasoning.

10. Section 3.2

   PRF_HMAC_SHA2_256 was not mentioned in RFC4307, as no SHA2 based
   authentication was mentioned.  

    s/authentication/transforms

11. Section 3.2

   PRF_HMAC_SHA2_512 SHOULD be implemented as a future replacement for
   PRF_HMAC_SHA2_256 or for when stronger security is required.

    Shouldn't "for when" be "when" from grammatical point of view? The same in Section 3.3.

12. Section 3.2

    PRF_AES128_CBC is not in the the IKEv2 IANA registry. There is PRF_AES128_XCBC instead.

13. Section 3.3

    There is some disconnect between Sections 3.1 and 3.3. Section 3.1 lists
    ENCR_AES_CCM_8 as the only preferred choice for IoT. However,
    ENCR_AES_CCM_8 is AEAD cipher, so if it is used then no separate
    authentication transform is needed. Why then AUTH_AES_XCBC_96
    is listed in Section 3.3 for IoT use case? What encryption transform
    it is intended to be used with in IoT? 

14. Section 3.4

    Note that
   it is critical to enforce a secure Diffie Hellman exchange as this
   exchange provides encryption for the session.  

    s/encryption/keys
    s/Diffie Hellman/Diffie-Hellman

15. Section 3.4

    If an attacker can
   retrieve the private numbers (for example a, b) (and? or?) the public
   values (for example g**a, g**b), then the attacker can compute the
   secret and the keys used and decrypt the exchange.  

    What is (and? or?)? Is it some leftover? Shouldn't it be just "and"?

16. Section 4.1

   RSA Digital Signature is widely deployed and therefor kept for
   interoperability.  

    s/therefor/therefore

17.Section 4.2

    Recommendations for when a hash function is involved in a signature:

    Shouldn't it be rephrased for more smooth reading?

18. Section 4.2

    The last table contains unexplained comment "?SHOULD".

19. Section 4.2

    In general this section leaves an impression that it is incomplete
    and contains disconnects. For example, it states that 
    RSASSA-PSS MUST be implemented, however a few lines
    below in a table I read: RSASSA-PSS with SHA-256 - SHOULD.
    I think more explanation text should be added.

Regards,
Valery Smyslov.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 22 Mar 2016 17:01:11 +0200

>     (well, I don't know if it is true, I'm not familiar with IoT world).

It matters when you use things like 802.15.9. IEEE 802.15.9 provides a
method to transport IKEv2 messages over IEE Std 802.15.4. In typical
PHY of the 802.15.4 the max frame size is 127 bytes, which leaves
about 96 bytes for the 802.15.9 for payload. Normal 300 byte IKEv2
packet will require about 3-4 fragments sent in 3-4 frames. Each of
those frames will be acknowledged, and there might be timing
constrains how often they can be sent (for example in TSCH network
this might be once per second at max, when using 10ms slot time, and
slotframe size of 100). 

If we raise the MAC size from 8 to 16, that will cause 8% probability
that we need one more frame to send that last part...

Also the speeds are low (around 200 kBit/s), and every single byte
transmitted consumes power... 

>     it is intended to be used with in IoT?

Because for example 802.15.4 devices use AES_CCM already, thus they do
have hardware to do AES_CCM, but they DO NOT have hardware to to AES
CBC (there is no AES decryption at all in the hardware). Implementing
AEAD is easier as it is just software for IKEv2, than adding AES
decryption to hardware.

On some other IoT devices the situation might be different. 

>     What is (and? or?)? Is it some leftover? Shouldn't it be just "and"?

Actual "or" is right. I.e., if attacker can get either one of the
private numbers, he can compute the secret. 
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 22 Mar 2016 18:23:00 +0300

HI Tero,

> that we need one more frame to send that last part...

That's a good reason. Shouldn't this (or similar) explanation be added to the draft?

> transmitted consumes power... 

That's also a valid reason. Again, shouldn't it be mentioned?

> AEAD is easier as it is just software for IKEv2, than adding AES

I understand that most IoT devices implement AEAD (AEC-CCM).
And in this case there is no need for them to use Integrity Transform at all.
But since the draft explicitely lists an Integrity Transform for use
in IoT world (AUTH_AES_XCBC_96), then some plain (non-AEAD) 
Encryption Transform for IoT must also be specified, 
so that they can be used together.

> private numbers, he can compute the secret. 

I read this "or" as "if attacker can retrieve private numbers or public values".
The attacker can always retrieve public values, - it is not the threat.
If the phrase is changed as you suggest - "if attacker can retrieve
either one of private numbers" then the phrase makes sense.

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 23 Mar 2016 23:01:29 +0200

> That's a good reason. Shouldn't this (or similar) explanation be

Perhaps. How much of current information we want to put in the
document. The things are changing all the time, and it might be true
now for IoT, but might not be true in few years. Isn't enough to just
say that currently this algorithm might be used for IoT.

> That's also a valid reason. Again, shouldn't it be mentioned?

Same as above.

> so that they can be used together.

AUTH_AES_XCBC_96 was there for before because it was replacement for
SHA-1 for general use, not only for IoT. When it was not taken in to
the use, it could also be removed or downgraded lower. On the other
there might be IoT devices which do not implement AES-CCM on hardware,
so AES-CBC + AUTH_AES_XCBC_96 might be suitable combination for them.
AES-CBC is already mandatory so there is no point of marking it as IoT
only. 

> I read this "or" as "if attacker can retrieve private numbers or
> public values". The attacker can always retrieve public values, - it
> is not the threat. If the phrase is changed as you suggest - "if
> attacker can retrieve either one of private numbers" then the phrase
> makes sense.

True, public values is know always, so there is no point of
"retrieving" them, I assumed it was supposed to be "(for example a, or
b)". In that case we could have also "and as attacker usually knows
pulic values"...
-- 
[email-masked]

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 27 Mar 2016 07:27:04 -0700

<no hat, but wanting to see more movement on this>

> say that currently this algorithm might be used for IoT.

That seems to be the right way to go.

--Paul Hoffman