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