Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-rfc4307bis

From: Yoav Nir <[email-masked]>
Date: Wed, 15 Feb 2017 19:10:58 +0200

One correction

> On 15 Feb 2017, at 19:05, Paul Wouters <[email-masked]> wrote:
> 
>>> Nit: You need only one of the public values and the complementary
>>> private value from the other side.
>> 
>> Right.
> 
> 

Instead of this:

>    exchange provides keys for the session.  If an attacker can retrieve
>    one of the private numbers (a, or b) with the corresponding public values (g**a, or g**b),
>    then the attacker can compute the secret and the keys used and

I suggest this:

>    exchange provides keys for the session.  If an attacker can retrieve
>    one of the private numbers (a or b) with the corresponding public values (g**b or g**a),
>    then the attacker can compute the secret and the keys used and

This way it’s more corresponding (and without the comma)

Yoav

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 15 Feb 2017 09:11:44 -0800

I would use "complementary" rather than corresponding.

-Ekr

On Wed, Feb 15, 2017 at 9:10 AM, Yoav Nir <[email-masked]> wrote:

>    one of the private numbers (a, or b) with the corresponding public
> values (g***a**,* or g***b*),
>    one of the private numbers (a or b) with the corresponding public
> values (g***b* or g***a*),
>

---

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Feb 2017 12:05:25 -0500

On 02/15/2017 02:35 AM, Yoav Nir wrote:
> Hi, Ekr.
> 
> Thanks for the review.  Comments inline.
> 
> On 15 Feb 2017, at 3:15, Eric Rescorla <[email-masked]> wrote:
> 
>> I had a few comments on this document
>>
>> S 3.1.
>>    ENCR_AES_GCM_16 was not considered 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 and key longevity compared to AES-CBC.  This resulted in
>>
>> It's not clear that GCM actually offers greater key longevity. Note that TLS is
>> recommending that far fewer than 2^{64} blocks of AES-GCM be encrypted
>> before changing keys.
> 
> When GCM was adopted for the first time (in both ESP and TLS) it was thought that it would offer greater key longevity than CBC. By now this has changed. I guess we can remove those three words.

I agree with removing the key longevity part.

>> S 3.4.
>>    the private numbers (a, or b) and the public values (g**a, and g**b),

I agree with rewriting this. How about:

And David noticed the reference for RFC7634 should be changed from normative to informative.

I'll do a new release with these changes if no one objects in the next day or so :)

Paul