This LGTM On Wed, Mar 29, 2017 at 11:07 AM, Daniel Migault < [email protected]> wrote:
> 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]> wrot >>>>> e: >>>>> >>>>>> >>>>>> 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
