[TLS] draft-ietf-tls-rfc4346-bis-09 LC comments (1)

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

Hello,
I'd like to once more submit a few comments on the current
 version of the TLS 1.2 Internet-Draft edited by you and now
 in IETF LC,  draft-ietf-tls-rfc4346-bis-09 ,
mostly addressing simple textual flaws I found in that memo.

Note:
  Due to time constraints, I only could perform a partial
  review -- maybe there will be a continuation next week.
  That's why I have added the number '(1)' to the subject.

The items below are presented in textual order.
To give more context, sometimes I quote larger blocks of text
literally and show the replacement proposed using the shorthand
notation:

   <original draft text>
---
   <modified text>

I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.  I also try to accomodate published
RFC-Ed policy on style and punctuation etc. in my proposals.


(0)  General

I found a few places that apparently have been overlooked in
performing updates according to the goals presented in section
1.2.  In such cases, I have tried to supply text that conforms
with these aims and other text already present in the draft,
without further rationale.


(1)  Section 1

According to the new primary cipher suite, I suggest to remove
references to legacy cryptographic algorithms in the Introduction.
To this end:

o  in the 2nd paragraph    s/DES/AES/g

o  in the 3rd paragraph    s/(e.g., SHA, MD5, etc.)/(e.g., SHA)/

In the 5th paragraph, I suggest     s/DSS [DSS]/DSA [DSS]/
(see item (4) below for rationale).  Furthermore, this change is
consistent with text already present in 7.4.1.4.1.

This same change should also be applied in section 7.4.3
(2nd-to-last paragraph) and section 7.4.8 (last paragraph).


(2)  Section 1.2, 3rd bullet

   -  Substantial cleanup to the clients and servers ability ...
---
   -  Substantial cleanup to the client's and server's ability ...


(3)  Section 4.6

For clarity, please adjust the indentation in the declaration
(at the end of 4.6):

      struct {
          select (VariantTag) { /* value of selector is implicit */
              case apple:
                V1;   /* VariantBody, tag = apple */
              case orange:
|          case banana:
           ^^^
                V2;   /* VariantBody, tag = orange or banana */
          } variant_body;       /* optional label on variant */
      } VariantRecord;
---
      struct {
          select (VariantTag) { /* value of selector is implicit */
              case apple:
                V1;   /* VariantBody, tag = apple */
              case orange:
|             case banana:
                V2;   /* VariantBody, tag = orange or banana */
          } variant_body;       /* optional label on variant */
      } VariantRecord;


(4)  Section 4.7

The current version of the DSS covers DSA, RSA, and ECDSA as well as
algorithm agility for use with the DSA.
Therefore, the text,

   In DSS, the 20 bytes of the SHA-1 hash are run directly through the
   Digital Signing Algorithm with no additional hashing. [...]

is misleading and confusing.  I suggest to change that to say:

         vvvvvvvvvvvvvvvvvvvvvvvvv
|  In DSS using the DSA with SHA-1, the 20 bytes of the SHA-1 hash are
   run directly through the Digital Signing Algorithm with no additional
   hashing. [...]

The subsequent 'Note' in the draft is very unfortunate, and BTW, wrong:
The terminological distinction between DSS and DSA already has been
clearly stated in the draft versions of the first edition of the
DSS, the original FIPS 186.
Thus, this is not "current terminology", it is "native terminology".

Wouldn't it be wise to restrict the use of "DSS" (in place of "DSA")
to within the (legacy) presentation language, and strictly make use
of the correct terminology in the prose ?

Besides the changes already mentioned in item (1) above, this
 recommendation includes using "DSA key" and "DSA certificate".


(5)  Section 6.1

The presentation language comment in front of the declaration
of struct SecurityParameters says:

|     /* The algorithms specified in CompressionMethod,
         BulkCipherAlgorithm, and MACAlgorithm may be added to. */

TLS 1.2 adds PRF agility. Hence, it should say:

|     /* The algorithms specified in CompressionMethod, PRFAlgorithm,
         BulkCipherAlgorithm, and MACAlgorithm may be added to. */


(6)  Section 6.3

Typo in the 1st line:   s/to generates keys/to generate keys/

                                     ^
(7)  Section 7

   cipher spec
|     Specifies the bulk data encryption algorithm (such as null, DES,
|     etc.) and a MAC algorithm (such as MD5 or SHA). It also defines
      cryptographic attributes such as the mac_length. (See Appendix A.6
      for formal definition.)
---
   cipher spec
|     Specifies the pseudorandom function (PRF) used to generate keying
|     material, the bulk data encryption algorithm (such as null, AES,
|     etc.) and a MAC algorithm (such SHA-n).  It also defines
      cryptographic attributes such as the mac_length.  (See Appendix
      A.6 for formal definition.)

Rationale: see above!


Best 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]                     |
+------------------------+--------------------------------------------+

_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls