> 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. > > 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) > 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. 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. > 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. Yoav
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
