On 5 Jan 2016, at 2:58, Valery Smyslov wrote:
Hi Paul,
thank you for your comments.
This draft makes me nervous, as compression has been removed from
encryption specifications in the last few years.
As far as I know IPcomp isn't deprecated, is it?
No, but that's not what PaulW said.
If you mean TLS, then as far as I understand the compression-related
attacks
on TLS rely on an ability for an attacker to insert specific data into
the
encrypted (and compressed) stream that contains secret information
(e.g. password). I don't think it's relevant to IKE and it is
discussed
in the Security Considerations section.
No one considered it relevant to TLS until researchers discovered the
problems there. I think that's PaulW's point, and one that I agree with.
I find the security
considerations also weak on this. It basically says "if you think
compression might be security issue, don't use it". Which isn't
helpful
at all to implementors.
Not really. It says that basically using compression in IKE should be
safe.
However, IF you transfer secret information inside an IKE SA and IF
some part of the IKE messages originates outside IKE,
then you are probably at risk. This could happen in case of EAP
authentication using weak EAP methods that transfer passwords in
clear. Note, that RFC 7296 strongly discourage
using such methods.
Note, that this is -00 draft and the security considerations
are currently very basic. What do you think should be added there?
That seems like a premature question. We haven't even decided if the
idea of compressing IKE would give the benefits listed, whether the
computational cost match the space benefits, and thus should be
considered at all.
--Paul Hoffman
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
