Subject: Re: [IPsec] secdir review of draft-ietf-ipsecme-rfc7321bis-05

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Mar 2017 09:12:21 -0400

On 03/14/2017 09:08 PM, Christian Huitema wrote:

Thanks for your review Christian!

> Adding Paul explicitly, since the forwarding through the draft.all alias
> does not pass through the gates of redhat.

Thanks, sorry for DMARC'ing issues. I did report it to our IT, but I doubt things will change :(

>> This document is ready for publication as a Proposed Standard, with some nits.
>>
>> My first set of nits concerns the keywords "SHOULD+", "SHOULD-" and "MUST-" that the 
>> draft is defining. These keywords would make an interesting update to RFC 6919. I 
>> understand that "SHOULD+" and "MUST-" are already defined and used in RFC 7321, and 
>> that you have at places to say "RFC 7321 said SHOULD+, but we change that to MUST". 
>> So maybe you should just note that "RFC 7321 defines these additional keywords".
>> Also, you never use SHOULD- in the text, so there is no need to define it. You
>> only MUST- once, to downgrade "AUTH_HMAC_SHA1_96" from MUST to MUST-. You could save 
>> space in the document by just adding a footnote for the SHA1 entry in the table,
>> stating that "this MUST means REALLY SHOULD NOT." Or maybe you really want to
>> update RFC 6919.

We really tried to keep the bis documents 4307bis and 7321bis close to the original so
that updates read easily. So even if we do not use one of the keywords now, we might in
a new version, so I think it is good for this set of documents to try and keep the same
keyword list.

>> The second set of nits contains manual keying. According to the draft, anyone using 
>> manual keying is punished for doing so, and will only be able to use ENCR_AES_CBC. I 
>> assume that there is WG consensus on that, but the justification that other algorithms
>> really require IKEv2 is a bit weak. If there is an API to configure encryption with the
>> results of an IKEv2 negotiation, it could just as well be used with the results of a
>> manual configuration. Not sure that the definition of algorithms is the best place to
>> deprecate manual configuration, even if there are some pretty good reasons to do that.

I answered this in the list already, but the short version is that any algorithm that
requires IVs to never repeat can never use manual keying because then there is no mechanism
to prevent re-using IVs, as most IV's are implemented as counters, which at some point will
overflow back to 0 and then the attacker can gain the private key knowledge.

Additionally, thre is no PFS when using manual keying, so any compromise could decrypt
all previous traffic. With IKE we are talking about 1-8 hours of session key lifetimes,
which are just beyond manual keying that stays in place with the same key for months, years
or worse.

I'm willing to explain the text a bit on this to clarify.

>> My last set of nits concerns the relation between this draft and the IANA registry of 
>> Internet Key Exchange Version 2 (IKEv2) Parameters. I understand that we have five states 
>> of specification or recommendation:
>> * MUST implement and MAY use algorithms such as ENCR_AES_GCM_16;
>> * SHOULD implement and MAY use algorithms such as ENCR_CHACHA20_POLY1305;
>> * SHOULD implement and MAY use but only for IoT devices, e.g. ENCR_AES_CCM_8;
>> * SHOULD NOT implement and MUST NOT use, e.g. ENCR_DES; Presumably, the code 
>>   has to be yanked from existing implementations.
>> * and then MAY implement and MAY use, e.g. ENCR_CAMELLIA_CBC.
>> But the fifth category is only specified by default, as "those algorithms that
>> are listed in the IANA registry but not referenced in the draft." I wonder whether there
>> is a way to express that clearly in the draft.

Since the tables are pretty big, that's a bit hard to do, and it would distract from the
very few prime algorithms we would like them to focus on.

Implementers I guess should have the IANA IKEv2 page open along with the RFC for the full
picture. I do want to say that for ipsec, the algorithms that are only in MAY are either
pretty new and have no deployment yet (curve25519, chacha20-poly1305) or are kind of
obsolete but no known attack against them has been successful (cast, serpent, twofish)

Paul