Hi Paul,
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.
IETF develops standards based on the best current knowledge.
For example today AES is considered secure, but there is a non-zero
probability that it'll be broken tomorrow. Shouldn't then we use it today?
Coming back to compression. As far as I understand compression per se was not a
problem
in TLS. The problem was that TLS mixed up secret information with user-provided
data and compressed it all together. The decision was to remove compression
from TLS (transport) and to move it to application level, because application
does know
what is safe to compress and what is not.
In case of IKE, IKE *is* an application. It shouldn't transfer any data that was
originated outside IKE. It does know what kind of data it transfers.
Moreover, no secret information is transferred in IKE SA. Some of information
is sensitive (like peers identities), but no passwords or keys are transferred.
Taking all these into considerations I think it is possible to use compression
in IKE without degrading its security. Of course there is no gurantee that
tomorrow all these consideration become wrong, but this could happen
with almost any security primitive IKE uses today.
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.
We couldn't decide if this idea is worth to use if we don't analyse
its security as deep as we can. I think that any new text in the
security considerations section will help us to make a right decision.
--Paul Hoffman
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
