Hi Yaron, Thanks Yaron for the comments so I updated my local copy replacing RFC4104 by RFC4106 ;-) I also assume that leaving AES-CTR is fine, and so keep it in the draft.
In the first version of the draft we described a way to have an implicit IV with AES-CBC. It was based on an additional key derivation for each direction and the IV was the sequence number encrypted with the key. During the presentation, we agreed that the additional complexity would not worth. The reason for that text is to make it clear that would be feasible. BR, Daniel On Mon, Jun 13, 2016 at 5:42 PM, Yaron Sheffer <yaronf.i...@gmail.com> wrote: > On 13/06/16 06:00, Yoav Nir wrote: > >> >> On 10 Jun 2016, at 5:39 PM, Yaron Sheffer <yaronf.i...@gmail.com >>> <mailto:yaronf.i...@gmail.com>> wrote: >>> >>> Hi, >>> >>> The document takes care to not define Implicit IV for AES-CBC, and I >>> believe the underlying reason is malleability of the encryption. The >>> same would apply to AES-CTR. So I would suggest to: >>> >>> * Exclude AES-CTR from this draft, or... >>> * Better yet, restrict the draft to AEAD algorithms. >>> >>> BTW, the reference for AES-GCM is incorrect. Should be 4106. >>> >>> Speaking of which, AES-GCM in ESP has a "salt" derived from IKE key >>> material. Is that kept intact by the current proposal? >>> >>> >> Hi, Yaron >> >> AES-CTR is pretty similar to AES-GCM and AES-CCM, except for the >> confusing terminology: >> >> * The 32-bit per-SA value derived from IKE is called “nonce” in RFC >> 3686 and “salt” in RFC 4106 (thanks for the corrected reference). >> * The concatenation of 32-bit per-SA value and IV is called “nonce” in >> RFC 4106 and doesn’t have a name in RFC 3686. >> * The concatenation of 32-bit per-SA value, IV, and block counter is >> called “counter block” in RFC 3686, but isn’t explicitly mentioned >> in RFC 4106. The GCM spec also calls it “counter block”. >> >> >> AFAICT it is not malleable like CBC. In CBC the issue was that an >> attacker knowing the next IV would be able to generate the first block >> of the next message such that IV xor Block0 would be whatever the >> attacker wanted. That block would be the input to the encryption >> function and thus the attacker could force the encryptor to encrypt >> whatever block it wanted. With counter mode (or GCM or CCM) the attacker >> has no control on the inputs to the encryption function. That is why RFC >> 3686 has text similar to the other documents: >> >> The same >> IV and key combination MUST NOT be used more than once. The >> encryptor can generate the IV in any manner that ensures uniqueness. >> Common approaches to IV generation include *incrementing a counter* >> for >> each packet and linear feedback shift registers (LFSRs). >> >> So I think CTR belongs in this draft as much as the others. >> >> And yes, the GCM salt or the CTR nonce are derived in the same way and >> used in the same way. >> >> Yoav >> >> > AES-CTR is potentially malleable by a MITM who can change counter values > into ones she'd observed before. However since RFC 3686 is very emphatic > about the need for integrity protection (Sec. 3.3), we should be fine. > > Thanks, > Yaron > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
