Re: [IPsec] WGLC on draft-ietf-ipsecme-rfc4307bis-11

["Valery Smyslov" <[e-mail]>]

Hi Paul, 

> We have kept key lengths out of the tables on purpose. It matches the
> tables at IANA that also do not list separate items for different key
> lengths. Would "This requirement" instead of "This requirement level"
> make that more clear?

If you don't want to add key length column to the table,
(what I think is a preferred way) then I suggest to add some
words to corresponding paras that will reiterate:
"these requirements are for those key sizes".

>> And the comment (IoT) brings even more confusion. It states that
>> "only 128-bit keys are at MUST level", while the line it refers to 
>> (ENCR_AES_CCM_8) indicates SHOULD level.
>
> That is an error. It should read "only 128-bit keys are at the SHOULD level"

OK. 

And again I think it should be reiterated in the text below the table (besides the comment).

> Note that I was hoping the (1) and (IoT) comments would appear similarly
> indented so it becomes a little more clear and was planning to ask the
> RFC Editor to ensure that.

I was thinking of complaining about their current appearance
(idented would be definitely better), but then I decided
that it is a feature of xml2rfc. But you are right that RFC Editor
can make them more better-looking.

>>   ENCR_AES_CBC is raised from SHOULD+ in [RFC4307] to MUST.  It is the
>>   only shared mandatory-to-implement algorithm with RFC4307 and as a
>>   result it is necessary for interoperability with IKEv2 implementation
>>   compatible with RFC4307.
>>
>> However, it is not exactly true. The comment (1) indicates that both
>> AES-128-CBC and AEC-256-CBC are now MUST, while in RFC4307 AES-256-CBC wasn't 
>> mentioned at all, so it definitely wasn't SHOULD+.
>> So, this statement is true for AES-128-CBC and not true for AES-256-CBC.
>
> It is only because you do not want to see ENCR_AES_CBC without a key
> size. We are talking about updating IANA entries, and the IANA entries
> are not separate for keysize.

We are talking about updating RFC4307 and it does include key size for AES-CBC (Section 3.1.1):

   For confidentiality, implementations
   MUST- implement 3DES-CBC and SHOULD+ implement AES-128-CBC.  For
   integrity, HMAC-SHA1 MUST be implemented.

Note, that it explicitely references AES-CBC with 128 bit key length, not any other.

>> Section 3.2
>>
>>   If an algorithm is selected as the integrity algorithm, it SHOULD
>>   also be used as the PRF. 
>>
>> That requirement isn't clear for me. Where it comes from?
>> How it is justified? Is the document in the position to make such restrictive 
>> requirement? Isn't it a local policy matter?
>
> It came from me, after having talked to Tero about a TAHI test suite
> test case. From what I understand from Tero, historically it was not
> mandated in the IKEv2 RFC to use the same algorithm, although there is
> really no argument in favour of using two different algorithms. If the
> algo is good enough for INTEG, it is good enough for PRF. If one algo
> is not good enough for either INTEG or PRF, then it is also not good
> enough for the other.
>
> Our implementation does not allow one to specify a PRF different from
> INTEG (unless INTEG is AUTH_NONE with an AEAD ENCR)
>
> I believe we ended up on SHOULD instead of MUST so this could be seen
> as advise, and not a hard requirement. So it does not update the IKEv2
> core RFC in that respect.
>
> Do you have any use case where it makes sense that PRF != INTEG ?

Sure.

First, not any good MAC is a good PRF (but vice versa is true).

Secondly, besides cryptographic properties there are also other
considerations, like performance. For example, in Russia
there is a standard MAC that is based on GOST cipher
with reduced number of rounds. It is very fast, but it cannot
be used as PRF.

Coming back from Russian quirks, I can imagine the situation when 
I want to use SHA2-512 for PRF (because I don't want my conversation
to be hacked offline in the future), but SHA1-HMAC-96 for MAC 
(because ICV tags are smaller comparing to SHA2 and I'm pretty 
confident in HMAC SHA1 security against _real_time_ attacks). 

And finally, I strongly oppose including such a restriction in 
this document, because from my point of view it is out of scope
of the document. It has nothing with defining requirement
levels for algorithms. Moreover SHOULD is a pretty strong requirement...

>>   PRF_HMAC_SHA1 has been downgraded from MUST in RFC4307 to MUST- as
>>   their is an industry-wide trend to deprecate its usage.
>>
>> I think some more reasons should be given besides "an industry-wide trend".
>> Industry usually follows standards, so it's a bit silly to refer to industry 
>> trends
>> as a reason here. I think some words about current concerns in the security
>> of SHA1 should be added (like for PRF_HMAC_MD5 below).
>
> How about:
>
>  "as cryptographic attacks against SHA1 are increasing, resulting in an
>  industry-wide trend to deprecate its usage"

OK.

>> Section 3.3
>>
>>   AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC4307 to MUST-
>>   as there is an industry-wide trend to deprecate its usage.
>>
>> See my comment above to the similar sentence in Section 3.2
>
> Same.

OK.

>>   It has been recommended by the CRFG and others as an
>>   alternative to AES-CBC and AES-GCM.
>>
>> What "others" mean? Isn't it too vague wording for Standards Track RFC?
>> Either list these "others" (at least some of them) or remove reference to 
>> them.
>
> Agreed. I will propose removing "and others".

OK.

>> Section 3.2
>>
>>   PRF_HMAC_SHA2_256 was not mentioned in RFC4307, as no SHA2 based
>>   transforms were mentioned.
>>
>> This sentence makes little sence for me. Shouldn't second "mentioned" be 
>> "defined at that time"?
>
> They might have been defined, but what matters is that the document did
> not reference them. Perhaps:
>
>    As no SHA2 based transforms were referenced in RFC4307, PRF_HMAC_SHA2_256
>    was not mentioned in RFC4307.

Works for me.

>>   AUTH_AES-XCBC is only recommended in the scope of IoT, as Internet of
>>   Things deployments tend to prefer AES based pseudo-random functions
>>   in order to avoid implementing SHA2. 
>>
>> s/AUTH_AES-XCBC/AUTH_AES-XCBC_96    (as in IANA Registry)
>
> Actually, we should add this to section 9 for renaming and call it
> AUTH_AES_XCBC_96.

Actually, it is already called AUTH_AES_XCBC_96 in the IANA registry.
I wanted to point that it is erroneously called AUTH_AES-XCBC in this paragraph.

>> Section 3.4
>>
>>   Group 19 or 256-bit random ECP group was not specified in RFC4307, as
>>   this group were not specified at that time. 
>>
>>
>> See my comment above about similar sentence in Section 3.2
>
> The second "specified" here could be changed to "define" ?

OK.

> Paul

Regards,
Valery.