Two comments to the new version:
- I suggest you add a reference to RFC 7427 (Signature Auth).
- We still have SHA1 as a MUST in Sec. 4.2. Shouldn't it be deprecated,
at least to MUST- ?
Thanks,
Yaron
On 01/05/2016 03:31 AM, internet-dra...@ietf.org wrote:
A New Internet-Draft is
On Fri, 8 Jan 2016, Yaron Sheffer wrote:
Two comments to the new version:
- I suggest you add a reference to RFC 7427 (Signature Auth).
Will do.
- We still have SHA1 as a MUST in Sec. 4.2. Shouldn't it be deprecated, at
least to MUST- ?
Yes, it was forgotten there when we added that
Hi Yoav,
First, the problem of IKE having too large packets in certain environments is a
real problem.
We’ve already addressed it with fragmentation, and the TCP encapsulation draft
proposes yet another way.
I don't think that compression is an alternative to TCP encapsulation. TCP
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
On Fri, 8 Jan 2016, Valery Smyslov wrote:
Third, I haven’t tested this myself, so I may be all wrong here, but I
question the value of compression on IKE.
IKE is a binary protocol with mostly compact binary payloads. Even the
list of supported CAs is a list of hashes in IKEv2.
How much can
