Hi Scott,
Thanks for the feed back, this is clearly some text that needs to be added
to draft. So options to deal with the compression of the ICV are:
- a) Allowing ICV compression with some restrictions like the ones you
mention.
- b) Not allowing ICV compression and explicitly listing encryption
algorithms with small ICV
BR,
Daniel
On Tue, Feb 17, 2015 at 10:17 PM, Scott Fluhrer (sfluhrer) <
[email protected]> wrote:
> 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]> 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]] *On Behalf Of *Daniel
> Migault
> *Sent:* Monday, February 16, 2015 10:08 PM
> *To:* [email protected]
> *Cc:* [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
>
>
>
>
> --
>
> Daniel Migault
>
> Ericsson
>
--
Daniel Migault
Ericsson
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
