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) <
sfluh...@cisco.com> 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:ipsec-boun...@ietf.org] *On Behalf Of *Daniel
> Migault
> *Sent:* Monday, February 16, 2015 10:08 PM
> *To:* 6...@ietf.org
> *Cc:* ipsec@ietf.org
> *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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
