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 protected]> wrote: > 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 > >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
