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 option. - The new transform ID is easy to add to implementations because it is just another value for an existing field. There is a slight downside in needing new ID allocations for what will be essentially a duplicate algorithm, but numbers are cheap. I think this is the easiest option to adopt and pass between implementation layers (userspace, kernel, etc), but once the layer doing encryption is using the value, it will probably want to flatten the information out into the original algorithm value and a flag that the IV is implicit. - A new transform attribute is attractive as a clean protocol design, since it seems to be the type of information that transform attributes are meant to hold. There aren't many uses of transform attributes currently, so this may add work to protocol parsers. This may require passing the flag for implicit IVs separately throughout the implementation, rather than as part of the transform ID, but I would be willing to do this as an implementer for the sake of a cleaner protocol. As such, I vote for either option 2 or 3: 2 for ease of implementation, 3 for clean protocol design. Thanks, Tommy > On Jun 9, 2016, at 9:19 AM, Daniel Migault <[email protected]> > wrote: > > Hi, > > Please find our new proposal with ESP using implicit IV [1]. We would like to > present and discuss it at the next IETF meeting. > > We would be happy to have the WG opinion on which you think is the better way > to negotiate the implicit IV between two peers. The different options are > detailed in section 5 and copy paste here in the email: > > """ > Negotiation of the use of implicit IV can be done in 3 different > ways: > > o An IMPLICIT IV Transform Type. A proposal that contains this > transform type requires (if accepted) that IPsec use the implicit > IV and not include an explicit IV in the packets. To facilitate > backward compatibility with non-supporting implementations the > Initiator SHOULD add another proposal that does not include this > transform type as well as cryptographic suite the Initiator does > not support the implicit IV. > > o An IMPLICIT IV Transform ID. This doubles the number of ENCR > transform IDs by creating an ENCR_AES_CCM_16_IIV for each > ENCR_AES_CCM_16. > > o An IMPLICIT IV Transform Attribute, which would be associated to a > Transform Type ID, specifying the use of an implicit IV. marks a > particular ENCR transform as using implicit IVs. To facilitate > backward compatibility with non-supporting implementations the > Initiator SHOULD add another ENCR transform for each algorithm so > marked. In other words, for each ENCR_AES_CCM_16 with > keylength=256 and IIV=1, there will need to be an ENCR_AES_CCM_16 > with keylength=256 and no IIV attribute. > > """ > > [1] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Thursday, June 09, 2016 12:12 PM > To: Tobias Guggemos; Yoav Nir; Daniel Migault > Subject: New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt > > > A new version of I-D, draft-mglt-ipsecme-implicit-iv-00.txt > has been successfully submitted by Daniel Migault and posted to the IETF > repository. > > Name: draft-mglt-ipsecme-implicit-iv > Revision: 00 > Title: Implicit IV for Counter-based Ciphers in IPsec > Document date: 2016-06-09 > Group: Individual Submission > Pages: 7 > URL: > https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-implicit-iv-00.txt > Status: > https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ > Htmlized: https://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-00 > > > Abstract: > IPsec ESP sends an initialization vector (IV) or nonce in each > packet, adding 8 or 16 octets. Some algorithms such as AES-GCM, AES- > CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not > require an unpredictable nonce. When using such algorithms the > packet counter value can be used to generate a nonce, saving 8 octets > per packet. This document describes how to do this. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
