[IPsec] draft-kato-ipsec-camellia-gcm-02 remaining editorials

[Alfred Hönes <[e-mail]>]

Hello once more,
to complete my follow-up work for your Camellia related I-Ds,
I also have addressed draft-kato-ipsec-camellia-gcm-02.

Generally, the spirit of the reasoning is the same as in my recent
editorial reviews for the sibling Camellia I-Ds.  Therefore, I now
use a more terse style.  (Please feel free to ask back if it turns
out that I'm not clear enough.)


(1)  Document Title

Since Camellia-GCM as specified in the draft (and btw any instance
of GCM in general) withing IPsec only applies to ESP (not to AH)
and you do not specify IKEv2-internal use of Camellia-GCM, I suggest
to clarify and amend the document title accordingly.  Beyond that,
"Modes of Operation" and "Modes" are synonym, which allows to simplify
the headline.  Altogether, I suggest to modify the title as follows:

The Use of Galois/Counter Mode (GCM) Modes of Operation for Camellia and
                           Its Use With IPsec
---
|  The Use of Galois/Counter Mode (GCM) for the Camellia Block Cipher
|                            With IPsec ESP


(2)  Section 1

(2a)  1st para -- punctuation

The commas are not neded:

   This document describes the use of the Camellia block cipher
|  algorithm in GCM Mode (Camellia-GCM) , as an IPsec ESP mechanism to
|  provide confidentiality, and data origin authentication.  We refer to
   this method as Camellia-GCM-ESP.
---
   This document describes the use of the Camellia block cipher
|  algorithm in GCM Mode (Camellia-GCM) as an IPsec ESP mechanism to
|  provide confidentiality and data origin authentication.  We refer to
   this method as Camellia-GCM-ESP.

(2b)  2nd para

<< same as for the sibling drafts! >>

(2c)  3rd para

I suggest to insert "encryption" for clarity and as a counterpart
to "authentication":

|  GCM mode provides Counter mode (CTR) with data origin authentication.
   This document does not cover implementation details of GCM.  Those
   details can be found in [1].
---                                    vvvvvvvvvvvv
|  GCM mode provides Counter mode (CTR) encryption with data origin
   authentication.  This document does not cover implementation details
   of GCM.  Those details can be found in [1].


(3)  Section 2 -- grammar

   Camellia-GCM comply with [2] on following points:
---                  vvv          vvvvvv
   Camellia-GCM complies with [2] in the following points:

And I would add to the end of this section a short description of
what makes the difference (after all these similarities) :

|
|  The only difference is the use of the Camellia block cipher primitive
|  instead of the AES block cipher primitive.


(4)  Section 3 -- punctuation

The first commas is not neded:

   This section describes the conventions used to generate keying
|  material and salt values, for use with Camellia-GCM-ESP, using the
   Internet Key Exchange (IKE) [4] protocol.  [...]
---
   This section describes the conventions used to generate keying
|  material and salt values for use with Camellia-GCM-ESP, using the
   Internet Key Exchange (IKE) [4] protocol.  [...]


(5)  Sections 3.2 and 3.3 -- IKE Terminology

The draft uses terminology from the old IKE (v1) : "Phase 1" and
"Phase 2".
Since you only address IKEv2 [4], that's confusing, and it would
be better to switch to IKEv2-specific terms: "Initial Exchange",
"CREATE_CHILD_SA Exchange", and "INFORMATIONAL Exchange".


(6)  Section 4

The abbreviation "TV" for "Test Vector" is not used anywhere else
in the draft and hence "(TV)" should be deleted from the first
text line in Section 4.


(7)  Section 5, 1st paragraph

Please consult my suggestions for the sibling drafts for possible
similar textual improvements.


(8)  Section 6

For added precision, I recommend to indicate *which* IANA registry
shall be updated and in which sub-registry the assignment shall
be performed, using the words from the registry file as a precise
guide to IANA and prospective readers of your future RFC:

|  IANA has assigned three ESP Transform Identifiers for Camellia-GCM
|  with an eight-byte explicit IV:
---
|  IANA has assigned three Transform Type 1 (Encryption Algorithm)
|  Identifiers for Camellia-GCM with an eight-byte explicit IV in the
|  "IKEv2 Parameters" registry:

Because of anecdotal evidence of previous trouble, the table should
perhaps be amended to show precisely the entries for these transforms
you would like to see registered:

|        <TBD1> for Camellia-GCM with an 8 octet ICV;
|        <TBD2> for Camellia-GCM with a 12 octet ICV; and
|        <TBD3> for Camellia-GCM with a 16 octet ICV.
---
|      Number    Name                                     Reference
|      --------  ---------------------------------------  -----------
|      <TBD1>    Camellia-GCM with an 8 octet ICV         [RFCxxxx]
|      <TBD2>    Camellia-GCM with a 12 octet ICV         [RFCxxxx]
|      <TBD3>    Camellia-GCM with a 16 octet ICV         [RFCxxxx]
|
|  [[ IANA and RFC Editor: please substitute the RFC number assigned
|     to this document for 'xxxx' above.  ]]


BTW, IPSECME folks:
  I would appreciate if IANA could fix the current entry in the above
  registry for AES-GCM-8  _without_  consuming additional cycles of
  the IESG, when touching this registry for the memo under review:

       18        AES-GCM with a 8 octet ICV               [RFC4106]
---                            v
       18        AES-GCM with an 8 octet ICV              [RFC4106]

:-)


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+