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]> 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/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
