Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx

[Yoav Nir <[e-mail]>]

> On 19 Mar 2017, at 19:30, Eric Rescorla <[e-mail]> wrote:
> 
> 
> 
> On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir <[e-mail] <mailto:[e-mail]>> wrote:
> 
>> On 19 Mar 2017, at 16:55, Eric Rescorla <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Overall:
>> I notice that you are using a construction different from that used
>> in TLS 1.3, which doesn't directly repeat nonces across associations.
> 
> I didn't see an answer to this.

Nonces are specified as 64-bit IV (usually counter and we are forcing it to be a counter) plus 32-bit salt in RFC 4106.  We saw no reason to change that.

>> 
>> S 2.
>>    This document does not consider AES-CBC ([RFC3602])as AES-CBC
>>    requires the IV to be unpredictable.  Deriving it directly from the
>>    packet counter as described below is insecure.
>> 
>> Can you provide a cite for this?
> 
> Even RFC 3602 requires that the IV be randomly generated (and for good measure requires that it be unpredictable)
> 
> That's just a cite to a requirement, not to it being insecure. Do you have a citation to the relevant threat?

We could cite BEAST. Of course BEAST depends on HTTPS, so it’s not really applicable - it’s harder to manipulate the first 16 bytes of the IP header - but these have been the recommendations for using CBC in both RFCs and NIST documentations for years before BEAST.

> 
>> In any case, note that there are
>> straightforward algorithms for deriving a CBC IV from a counter
>> (e.g., run AES in counter mode with a different key). That structure
>> would actually be suitable for GCM as well (and would address
>> my point above).
> 
> If each implementation generates a random key and uses this to generate the IVs this is fine, but you still have to transmit the IV.  If we derive an “IV key” from the keying material, then we don’t have to transmit the IV.
> 
> You generate the IV from the sequence number, so you don't need to transmit the IV.
> That gives you an unpredictable IV without the per-packet overhead.
> 
> 
> We did bring this idea up at a WG meeting. This was not well-received for three reasons: (1) it’s unnecessarily complicated. (2) The world is going to AEAD. AES-CBC is the past, and (3) The perception was that saving 8 bytes per packet was important mostly for IoT, and they don’t care about CBC.
> 
> Sure, that's reasonable. I'm merely observing that there are designs which work for CBC.
> 
> 
>> S 3.
>>    o  IV: Initialization Vector.  Although security requirements vary,
>>       the common usage of this term implies that the value is
>>       unpredictable.
>> 
>> I don't think that this is true at all. I've frequently heard of a
>> zero IV. It's also odd in that your IV is in fact predictable.
>> 
>> 
>> S 5.
>> I'm a bit surprised that you are deciding to have duplicate
>> code points for every algorithm rather than some sort of IKE
>> negotiation payload. I see that the WG is currently defining
>> other extensions where you take that approach.
> 
> See slide #7 of https://www.ietf.org/proceedings/96/slides/slides-96-ipsecme-0.pdf <https://www.ietf.org/proceedings/96/slides/slides-96-ipsecme-0.pdf>
> 
> The problem is that IKEv2 has strict rules about unexpected attributes in the substructures of the SA payload. The sense of the room was to go with new identifiers.
> 
> OK. Well, I agree it's ultimately a WG decision, but it doesn't seem very elegant.

I was in the rough on this at first, but it was shown that every alternate negotiation mechanism had unwanted consequences.

Yoav