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
