> On 19 Mar 2017, at 19:30, Eric Rescorla <e...@rtfm.com> wrote: > > > > On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir <ynir.i...@gmail.com > <mailto:ynir.i...@gmail.com>> wrote: > >> On 19 Mar 2017, at 16:55, Eric Rescorla <e...@rtfm.com >> <mailto:e...@rtfm.com>> 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. >> >> 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. > >> 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 > <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. I was in the rough on this at first, but it was shown that every alternate negotiation mechanism had unwanted consequences. Yoav
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
