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 protected]> wrote: > 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 protected]> wrote: > >> >> >> On Sun, Mar 19, 2017 at 11:52 AM, Yoav Nir <[email protected]> wrote: >> >>> >>> On 19 Mar 2017, at 19:30, Eric Rescorla <[email protected]> wrote: >>> >>> >>> >>> On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir <[email protected]> wrote: >>> >>>> >>>> On 19 Mar 2017, at 16:55, Eric Rescorla <[email protected]> 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. >>> >> >> OK. This has a somewhat lower margin of safety than the TLS 1.3 >> construction, but it should be OK. >> >> >> 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. >>> >> >> Sure. I just think claims like this should have a citation. >> >> >> -Ekr >> >> >>> 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/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. >>>> >>> >>> 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 >>> >>> >> >> _______________________________________________ >> IPsec mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
