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

From: Eric Rescorla <[email-masked]>
Date: Sun, 19 Mar 2017 07:55:30 -0700

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.

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? 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).

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.

-Ekr

---

From: Yoav Nir <[email-masked]>
Date: Sun, 19 Mar 2017 19:23:12 +0200

> On 19 Mar 2017, at 16:55, Eric Rescorla <[email-masked]> wrote:
> 
> Overall:
> 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)

> In any case, note that there are

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.

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.

> 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.

Yoav

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 19 Mar 2017 10:30:14 -0700

On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir <[email-masked]> wrote:

> I didn't see an answer to 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?

> 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.
> See slide #7 of 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.

-Ekr

---

From: Yoav Nir <[email-masked]>
Date: Sun, 19 Mar 2017 20:52:55 +0200

> On 19 Mar 2017, at 19:30, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On 19 Mar 2017, at 16:55, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Overall:

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.

> 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.

> You generate the IV from the sequence number, so you don't need to transmit the IV.
> Sure, that's reasonable. I'm merely observing that there are designs which work for CBC.
> 
> 
>> S 3.
> 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

---

From: Daniel Migault <[email-masked]>
Date: Sun, 19 Mar 2017 14:55:32 -0400

S 2.

> a citation to the relevant threat?

Predictable IV can be exploited by chosen plain text attacks. RFC3602 cites
[CRYPTO-B] in teh sceurity consideration section:
"""

For more information regarding the necessary use of random IV values,
see [CRYPTO-B <https://tools.ietf.org/html/rfc3602#ref-CRYPTO-B>].

"""
with :

[CRYPTO-B]   Bellovin, S., "Probable Plaintext Cryptanalysis of the
             IP Security Protocols", Proceedings of the Symposium on
             Network and Distributed System Security, San Diego, CA,
             pp. 155-160, February 1997.
             http://www.research.att.com/~smb/papers/probtxt.pdf

This links works:
https://www.cs.columbia.edu/~smb/papers/probtxt.pdf

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 19 Mar 2017 12:05:15 -0700

On Sun, Mar 19, 2017 at 11:52 AM, Yoav Nir <[email-masked]> wrote:

> 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.
>

OK. This has a somewhat lower margin of safety than the TLS 1.3
construction, but it should be OK.

S 2.
> 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.
>

Sure. I just think claims like this should have a citation.

-Ekr

>> See slide #7 of https://www.ietf.org/proceedings/96/slides/slides-96-
>> ipsecme-0.pdf
>>
> I was in the rough on this at first, but it was shown that every alternate
> negotiation mechanism had unwanted consequences.
>
> Yoav
>
>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 29 Mar 2017 10:52:05 -0500

Hi Eric,

Thank you  for the review and comments. Do you have any preference on what
we should cite for the chosen clear text attack?: Our local version
currently refers to Security Consideration of RFC3602.

The sentence in the terminology section mentioning that IV are usually
unpredictable has been removed. Thanks for catching that.

Yours,
Daniel

On Sun, Mar 19, 2017 at 2:05 PM, Eric Rescorla <[email-masked]> wrote:

>>> See slide #7 of https://www.ietf.org/procee
>>> dings/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.
>>>
>>
>> I was in the rough on this at first, but it was shown that every
>> alternate negotiation mechanism had unwanted consequences.
>>
>> Yoav
>>
>>
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 29 Mar 2017 10:54:11 -0500

I think Yoav's suggestion to cite BEAST as evidence that predictable IVs
are bad is a good plan.

-Ekr

On Wed, Mar 29, 2017 at 10:52 AM, Daniel Migault <
[email-masked]> wrote:

>>> 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.
>>>
>>
>>> 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.
>>>>
>>>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 29 Mar 2017 11:07:57 -0500

I am planning to add this reference.Let me know if you prefer another
reference.

Rizzo, J. and T. Duong. "Here come the xor ninjas", 2011.
http://netifera.com/research/beast/beast_DRAFT_0621.pdf.

Thanks for the feed back.

Yours,
Daniel

On Wed, Mar 29, 2017 at 10:54 AM, Eric Rescorla <[email-masked]> wrote:

>> Thank you  for the review and comments. Do you have any preference on
>> what we should cite for the chosen clear text attack?: Our local version
>>>> 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.
>>>>
>>>
>>>>> 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.
>>>>>
>>>>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 29 Mar 2017 11:12:04 -0500

This LGTM

On Wed, Mar 29, 2017 at 11:07 AM, Daniel Migault <
[email-masked]> wrote:

> Rizzo, J. and T. Duong. "Here come the xor ninjas", 2011. http://netifera.com/research/beast/beast_DRAFT_0621.pdf.
>
>
>>>>>> Even RFC 3602 requires that the IV be randomly generated (and for
>>>>>> good measure requires that it be unpredictable)
>>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>