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