Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

Here are my thoughts on the options for communicating the Implicit IV option in the proposal: - A new transform type is problematic, as pointed out by Valery and Paul already, because it adds complexity to the proposal structure for configuring and parsing. This seems to be the least desirable

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

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.

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

On Fri, 10 Jun 2016, Yoav Nir wrote: All the algorithms we mention in the draft (AES-CTR, AES-GCM, AES-CCM, ChaCha20-Poly1305) require a nonce that is given in the IV field of an ESP packet. For all of those algorithms, the respective RFC recommends to use a counter to guarantee nonce

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

Hi, Paul On 10 Jun 2016, at 5:42 AM, Paul Wouters wrote: > On Thu, 9 Jun 2016, Daniel Migault wrote: > >> Please find our new proposal with ESP using implicit IV [1]. We would like >> to present and discuss it at the next IETF meeting. > > I must understand it wrong... > >