Hi Daniel,
thank you for addressing that. I have no problems with your text.
There are two nits, however. First: in phrase ”allow the Message ID to be
re-initialized”
I would use some other word instead of “re-initialized”, e.g. “reused”,
or “repeated”. And second: I would change “IANA is expected”
to “IANA is requested” or smth similar.
Regards,
Valery.
Hi,
This is the text I propose to address Valery comment regarding the IANA
consideration section. Let me know if you have any comment on that.
Yours,
Daniel
8. IANA Considerations
AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
implement the implicit IV described in this document. This section
limits assignment of new code points to the recommended suites
provided in [RFC8221], thus the new Transform Type 1 - Encryption
Algorithm Transform IDs are as defined below:
- ENCR_AES_CCM_8_IIV
- ENCR_AES_GCM_16_IIV
- ENCR_CHACHA20_POLY1305_IIV
[RFC8247] recommends the same suites for IKEv2. However some IKEv2
extensions such as [RFC6311] or [RFC7383] allow the Message ID to be
re-initialized, which is incompatible with the uniqueness property of
the nonce, and makes these suites highly insecure. Given that the
traffic associated to IKEv2 is expected to remain low compared to the
ESP traffic, the suites defined in this document MUST NOT be used for
IKEv2. The IANA is expected to put "Not allowed" in the column
"IKEv2 Reference" for these transforms.
On Mon, Oct 30, 2017 at 8:28 AM, Valery Smyslov <sva...@gmail.com> wrote:
Sorry, I made a typo (see below):
> 2. IANA Considerations
>
> AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
> implement the implicit IV described in this document. This section
> limits assignment of new code points to the recommended suites
> provided in [I-D.ietf-ipsecme-rfc4307bis] and
> [I-D.ietf-ipsecme-rfc7321bis], thus the new Transform Type 1 -
> Encryption Algorithm Transform IDs are as defined below:
>
> The newly defined IIV transforms are not applicable for IKEv2 (because
> there is no unique per message field;
> Message ID do can repeat, e.g. in case RFC6311 or RFC7383 is used). So,
> [I-D.ietf-ipsecme-rfc7321bis]
[I-D.ietf-ipsecme-rfc4307bis] of course.
> (now RFC8247) must not be referenced here. Moreover, I'd like to express
> this prohibition
> more explicitly in IANA registry, instructing IANA to put "Not allowed"
> in the column "IKEv2 Reference"
> for these transforms:
So, the correct text is:
AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
implement the implicit IV described in this document. This section
limits assignment of new code points to the recommended suites
provided in [I-D.ietf-ipsecme-rfc7321bis]. Note, that using implicit IV
for these
algorithms is defined for ESP only and is not allowed for protecting
IKEv2 messages.
IANA is requested to add the following transforms to the Transform Type
1 -
Encryption Algorithm Transform IDs registry for IKEv2, setting "ESP
Reference"
to this document and marking "IKEv2 Reference" as "Not allowed":
Regards,
Valery.
_______________________________________________
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
