Others have addressed my other points; let me talk about the specific issues with GCM.
One summary of the issues found is http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.297.9568&rep=rep1&type=pdf ; the problem with GCM is that: - With one successful forgery, the attacker can modify other packets the same way without detection. - With a handful of successful forgeries, the attacker can learn enough to be able to forge arbitrary messages. Now, with the full 16 byte ICV, this is not a concern (because the probability of the attacker finding one successful forgery is tiny); however once you start reducing the ICV value, well, various guessing strategies start working better. Now, neither HMAC nor CMAC has this problem; yes, with a tiny ICV, someone can generate a forgery by blindly guessing; however a successful forgery doesn’t give the attacker any information about how to generate a second successful forgery, or any information about the internal state. Instead, generating a second forgery requires just as much work as you’d expect (that is, the same amount of work taken to generate the first forgery). Hence, while I would suggest that you rethink the strategy of allowing tiny ICVs, if you do go ahead, I would strongly urge you to mandate the use of either HMAC or CMAC to generate those tiny ICVs – those won’t make a poor situation even worse. From: Daniel Migault [mailto:[email protected]] Sent: Tuesday, February 17, 2015 10:48 AM To: Scott Fluhrer (sfluhrer) Cc: [email protected]; [email protected] Subject: Re: [IPsec] Diet-ESP Hi Scott, Thank you for the feed back. I agree that compressing the ICV reduces security related to authentication. Let's call this a "weak authentication". I am not saying it is a valid argument, but since IPsec enables NULL authentication too, we considered that enabling "weak authentication" would be possible with a clear warning in the security consideration. The reason we are looking we are looking for weak authentication is to be able to balance authentication with bandwidth optimization. In fact, suppose you compute the mean/median over a thousand different value, that one or two values are corrupted may not have much impact overall, and we may prefer to extend the life time of the mote for 5 years instead. Regarding you comment I think the issue ou raised is more related to GCM. -- By the way I would be interested to have a description or relevant doc describing why ICV in GCM particularly matters. One way to address the issue you raised would be: - 1) mention the need for weak authentication in the requirement draft - 2) remove ICV compression from Diet-ESP - 3) Define encryption protocols with weak authentication with different sizes of the ICV. For example suppose AES-MODEX has an ICV of N, then we may need to add AES-MODEX_i with i in [0 ... N-1]. The advantage of doing so is that it avoids end user to weaken the protocols especially when one compression is fine with one protocol but not with the others. In that sense it looks a better design. However, I see the following drawbacks: - It requires to create multiple encryption protocols. Unlike compression, implementation cannot use existing implementation of AES-MODEX. - Negociation for hosts accepting all AES-MODEX_i with i in [0 ... N-1] requires many SA payload in the IKEv2 negotiation. However, we may deal with this with a AES-MODEX_ALL to indicate the responder choses its compression. BR, Daniel On Tue, Feb 17, 2015 at 6:28 AM, Scott Fluhrer (sfluhrer) <[email protected]<mailto:[email protected]>> wrote: Here’s an issue with this draft; it doesn’t meet the requirements that it claims. In particular, it claims that it is based on standard IPsec, and that its security is equivalent to IPsec (R1-R3). However, it allows (and, as far as I am concerned, encourages) the use of tiny ICVs; these tiny ICVs introduce security vulnerabilities that do not occur within sane configurations of IPsec (where sane includes using an integrity transform). In particular, using tiny ICVs with GCM is a known security issue. Now, it would be possible to have an encryption protocol that would not have issues with small ICVs (say, by using a wide block cipher); however this would be rather different than standard IPsec (in part because IPsec was never designed with these minimal bandwidth constraints); either we need to stay with an IPsec-based protocol (which implies a largish ICV), or go with something else (which would have less overhead, but doesn’t look that much like IPsec internally). Oh, and a minor note on the IV generation: it’s actually secure to use the same key you use to encrypt to encrypt the counter for the IV; you don’t need a separate key. From: IPsec [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Daniel Migault Sent: Monday, February 16, 2015 10:08 PM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: [IPsec] Diet-ESP Please find the new version of Diet-ESP a compress IPsec/ESP for IoT. We have implemented and tested Diet-ESP. Compared to the standard IPsec/ESP, Diet-ESP can reduce the networking overhead added to unprotected data from 100% to a few percent. I will be happy to present these draft next IETF. Feel free to make comments! The drafts includes: 1) draft-mglt-6lo-diet-esp-requirements<http://datatracker.ietf.org/doc/draft-mglt-6lo-diet-esp-requirements/>: lists the requirements for Diet-ESP 2) draft-mglt-6lo-aes-implicit-iv<http://datatracker.ietf.org/doc/draft-mglt-6lo-aes-implicit-iv/>: indicates how to avoid carrying the IV in each ESP packet. It is instead generated by each peers. The protocols described in the draft can be used with the regular IPsec/ESP. 3) draft-mglt-6lo-diet-esp<http://datatracker.ietf.org/doc/draft-mglt-6lo-diet-esp/> describes the core Diet-ESP protocol, that is how to compress/decompress each fields of the standard IPsec/ESP. Compression is discribed through a Diet-ESP Context. 4) draft-mglt-6lo-diet-esp-payload-compression<http://datatracker.ietf.org/doc/draft-mglt-6lo-diet-esp-payload-compression/>: describes how the clear text can be compressed before encryption. In fact unless IPsec/ESP is used with NULL encryption, the data in the ESP packet is encrypted. Encryption makes compression hard to perform. Instead compressing before encrypting can be very efficient. This makes possible to remove UDP/TPC/IP tunnel headers. 5) draft-mglt-6lo-diet-esp-context-ikev2-extension<http://datatracker.ietf.org/doc/draft-mglt-6lo-diet-esp-context-ikev2-extension/>: describes how to negociate Diet-ESP with IKEv2. In fact this mostly result in an agreement for the DIet-ESP Context. This exchange may then be extended to Diet-HIP Exchange. BR, Daniel -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58<tel:%2B33%206%2070%2072%2069%2058> -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
