Hi,
Do you have any opinion on the proposed alternative?
- 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].
BR,
Daniel
On Tue, Feb 17, 2015 at 5:07 PM, <[email protected]> wrote:
>
> > On Feb 17, 2015, at 10:47 AM, Daniel Migault <[email protected]>
> wrote:
> >
> > 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.
>
> That is not a valid analogy. NULL authentication specifically delivers no
> authentication at all. The security properties of “no authentication” are
> reasonably obvious even to people not skilled in cryptography.
>
> On the other hand, weak authentication can easily be mistaken for real
> authentication, in the same way that DES (or worse yet, DES-40) was in the
> past mistaken for real confidentiality. If we build a system with weak
> security properties, we run the very real risk that it may end up being
> widely used “to save bandwidth”, when in fact it should be considered as a
> niche solution that is only valid for extremely unusual scenarios. It’s
> not clear to me that a note in teh security considerations section will be
> sufficient.
>
> paul
>
>
--
Daniel Migault
Ericsson
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
