Thank you kindly for penning this draft. It's in very good shape for the
first iteration. However, I find that there are some areas which can be
improved so that an implementer can have an easier time engaging with the
document.
Primary Feedback:
In relation to the editorial comment "Is it acceptable to rename the IV
field to Nonce, or should this guidance use the same field name and just
clarify that the IV field contains the nonce instead of IV?" there seems to
be a historical precedent that the IV field should maintain its name as the
IV field, even if it should not be handled/interpreted as a traditional IV.
For reference, see RFC7634 Section 2 where the authors display the ESP
Payload Data structure, and outline how each substructure ought to be
interpreted for the purpose of encryption. With respect to RFC7634, the IV
field maintains its name, despite being treated as a fragment of a nonce
for the purpose of encryption.
Using RFC7634 as a reference point further, I think section 4 could benefit
from a visual. Namely, I'd recommend adding Figure 2 from RFC4303 and
outlining explicitly how each part of the structure will tie to a variable
from RFC8452. I think there would be value in tying the variables in this
draft concretely to something well established and understood. Though I
understand doing this may require repeating the well established image from
RFC4303 again when it could simply be cited, I think the benefit of making
the draft more self-contained is worth the minor repetition. I believe this
can be done in section 3 as well.
Minor Comments:
I find subsection 3.1 structurally more challenging to parse than the other
subsections of section 3. In subsection 3.1, novel components of
AES-GCM-SIV are interlaced with references to AES-GCM. I prefer the clear
partition between AES-GCM-SIV specification and comparison as done in
subsection 3.2, where the implementation leads the subsection, and the
comparison follows to provide context to how the implementation differs.
I feel the naming choice for citation FIPS197 is a tad misleading. FIPS 197
outlines the AES algorithm itself, however it does not describe any
specific modes of operation such as AES-GCM. Moreover, the document
"Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode
(GCM) and GMAC" was released 6 years after FIPS 197. It may instead be more
appropriate to label the citation as [SP-800-38D].
Nits:
s/{This is because the AES-GCM-SIV authentication tag is needed to decrypt
ciphertext}{This is because the AES-GCM-SIV authentication tag is needed to
decrypt the ciphertext}
Best,
Keegan Dasilva Barbosa
Canadian Centre for Cyber Security
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]