Re: [IPsec] AD review of draft-ietf-ipsecme-rfc7321bis

[Kathleen Moriarty <[e-mail]>]

Hi Paul,

On Fri, Feb 17, 2017 at 12:17 PM, Paul Wouters <[e-mail]> wrote:
> On Fri, 17 Feb 2017, Kathleen Moriarty wrote:
>
>> Thanks for your work on draft-ietf-ipsecme-rfc7321bis.  I just have
>> one big question and a nit to point out.
>>
>> Questions:  I see this:
>> 5.  ESP and AH Authentication Algorithms
>>
>>   Encryption without authentication MUST NOT be used.
>>
>> This is a big change from RFC7321 without much explanation. What about
>> the case of opportunistic security?  Can you explain the change and
>> justification?
>
>
> It is actually not much a change. If you look at 7321 Section 3, it states:
>
>         Confidentiality without authentication is not effective [DP07]
>         and therefore SHOULD NOT be used.

Yes, I saw that and agree security-wise that this is a bad practice.
But 7321 say a lot more on both ESP and AH authentication than that
one sentence.  What I am saying is that the change in this document
requires more text to explain it.

You also have the following text in that section:

   To provide both confidentiality and authentication, an authenticated
   encryption transform from Section 2.1 SHOULD be used in ESP, in
   conjunction with NULL authentication.

It's fine again with the following text:

   Alternatively, an ESP
   encryption transform and ESP authentication transform MAY be used
   together.  It is NOT RECOMMENDED to use ESP with NULL authentication
   in conjunction with AH; some configurations of this combination of
   services have been shown to be insecure [PD10].

Then at the end of the next paragraph:

   Therefore, an encryption
   transform MUST NOT be used with a NULL authentication transform
   (unless the encryption transform is an authenticated encryption
   transform from Section 2.1).

>
> Encryption without authentication is vulnerable to manipulation that can
> cause an oracle attack to compromise the encryption key as well.

yes.

>
> The 7321 document was a bit unclear with respect to encryption algos
> versus AEAD algos which might look like it allows a wider acceptance
> of encryption without authentication, but really does not intend to.

What I am saying is that it would be helpful to provide text to
explain the change.

>
>
>> Nits:
>> Section 4, third paragraph: s/theses/these/
>>
>>   Usually, the use of theses algorithms is limited to
>>   specific cases, and the absence of specification makes
>>   interoperability difficult for IPsec communications.
>
>
> I'll keep this in mind to correct at the RFC Editor round, unless we do
> another draft round if we need to change anything else.

Thanks.  I'd want it updated before IESG review, especially adding
text for the above changes.

>
> Thanks,
>
> Paul



-- 

Best regards,
Kathleen