Hi, Valery, Thank you for pointing this section. I assume that is section 8 RFC3686. I will send a new thread to discuss that. I think the motivation is provided in the introduction, that is reducing the size of the payload, which was considered as negligible overhead in RFC3686.
In addition RFC3686 specify that the use of an explicit IV instead of an implicit IV was not based on cryptographic considerations. However, I propose that the the Security Consideration section refer to the design section and explain how using the sequence number for the IV impacts the systems. For the vote I will come later to sum up the results. BR, Daniel On Fri, Jun 10, 2016 at 3:17 AM, Valery Smyslov <[email protected]> wrote: > Hi Daniel, > > a couple of comments. RFC 3686 Section 6 provides design rationale for > making an IV explicit. > I think it will be good if your draft also gives some design rationale why > you came > to the opposite conclusion (just to give readers an insight why in IoT > world > the weight of different factors might change dramatically comparing to > "big" world). > > 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. >> > > The problems with this option is that it adds additional interdependence > between > Transforms presenting in the Proposal. We already have this for AEAD > algorithms, which requires them to be placed in a separate Proposal > from non-AEAD ciphers. This complicates both encoders and parses > (I'd rather have separate Transform Type for AEAD ciphers, but that is > that). > With new Transform Type which is only applicable to some of Transform IDs > the things become even more complicated for no practical reason. > > 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. >> >> """ >> > > These two options are similar in terms of complexity. > I slightly prefer new Transform IDs over an Implicit IV Attribute since > in this case it is very clear from the IANA registry which ciphers > can be used with Implicit IV. > > Regards, > Valery. > > > [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 >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
