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

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

Hello,
as promised last week, I'd like to submit the second part of my
LC comments on the I-D edited by you, draft-ietf-tls-rfc4346-bis-09.

For ease of reference, I continue the item numbering from
the first part, msg-id <[e-mail]>,
and occasionally include by reference rationale explained there.


(8)  Section 7.3

The 4th paragraph below the bulleted list contains a typo:

   Following the hello messages, the server will send its certificate,
   if it is to be authenticated. Additionally, a server key exchange
|  message may be sent, if it is required (e.g., if their server has no
                                                       ^^
   certificate, or if its certificate is for signing only).  [...]
---
   Following the hello messages, the server will send its certificate,
   if it is to be authenticated. Additionally, a server key exchange
|  message may be sent, if it is required (e.g., if the server has no
   certificate, or if its certificate is for signing only).  [...]


(9)  Section 7.4.1.2

(9a) Outdated time base

In the initial part of this section, the draft still uses the outdated
time base, GMT, which hase been superseeded by UTC long ago.
I acknowledge that the names of the protocol elements should not
be changed for backwards compatibility, but I strongly suggest to
used UTC in the prose, and explaining the background in a short note.
Thus, I propose tyo change:

      gmt_unix_time
         The current time and date in standard UNIX 32-bit format
|        (seconds since the midnight starting Jan 1, 1970, GMT, ignoring
                                                           ^^^
         leap seconds) according to the sender's internal clock. Clocks
         are not required to be set correctly by the basic TLS Protocol;
         higher-level or application protocols may define additional
         requirements.
---
      gmt_unix_time
         The current time and date in standard UNIX 32-bit format
|        (seconds since the midnight starting Jan 1, 1970, UTC, ignoring
         leap seconds) according to the sender's internal clock. Clocks
         are not required to be set correctly by the basic TLS Protocol;
         higher-level or application protocols may define additional
|        requirements.  Note that, for historical reasons, the data
|        element is named using GMT, the predecessor of the current
|        world-wise time base, UTC.

(9b)  explanation of ClientHello field:  session_id

Please correct the typo:

   session_id
      The ID of a session the client wishes to use for this connection.
|     This field is empty if no session_id is available, or it the
      client wishes to generate new security parameters.
---                                                         ^^
   session_id
      The ID of a session the client wishes to use for this connection.
|     This field is empty if no session_id is available, or if the
      client wishes to generate new security parameters.
                                                            ^^
(9c)  explanation of ClientHello field:  compression_methods

For clarity (and conformance to RFC-Ed style), please add a comma:

   compression_methods
      This is a list of the compression methods supported by the client,
      sorted by client preference. If the session_id field is not empty
|     (implying a session resumption request) it MUST include the
      compression_method from that session. [...]
---
   compression_methods
      This is a list of the compression methods supported by the client,
      sorted by client preference. If the session_id field is not empty
|     (implying a session resumption request), it MUST include the
      compression_method from that session. [...]


(10)  Section 7.4.1.3

In the explanation of the ServerHello field:  session_id ,
I suggest adding the definite article in the last sentence,
for the sake of consistency in the style used almost everywhere
throughout the document:

|         [...]. Client MUST be prepared to do a full negotiation --
      including negotiating new cipher suites -- during any handshake.
---              vvvvv
|         [...]. The client MUST be prepared to do a full negotiation --
      including negotiating new cipher suites -- during any handshake.


(11)  Section 7.4.1.4

(11a)  Proactive consistency with upcoming FIPS PUB 186-3

The draft defines:

      enum {
          none(0), md5(1), sha1(2), sha256(3), sha384(4),
          sha512(5), (255)
      } HashAlgorithm;

The current and the recent draft version of the SHS also defines
SHA-224 and the draft version of the DSS [DSS-3] also makes
provisions for using SHS-224 with all signature algorithms
specified there (DAS, RSA, and ECDSA), subject to (key) size
restrictions; in particular, FIPS PUB 186-3 allows the use of SHA-224
for DSA with L=2048.  The new version of TLS should align with this
upcoming standard as far as practical.

Therefore,
I strongly suggest to immediately assign a HashAlgorithm code point
for SHA-224 and not defer this action to a separate document:

      enum {
|         none(0), md5(1), sha1(2), sha224(TBA), sha256(3), sha384(4),
          sha512(5), (255)
      } HashAlgorithm;
                                    ^^^^^^^^^^^^^

(11b)  explanation of the signature field

For completeness and consistency with the definition of the
SignatureAlgorithm,

      enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
        SignatureAlgorithm;

... I suggest to also mention the ECDSA alternative there:

   signature
      This field indicates the signature algorithm which may be used.
      The values indicate anonymous signatures, RSASSA-PKCS1-v1_5
|     [PKCS1] and DSA [DSS] respectively. The "anonymous" value is
      meaningless in this context but used in Section 7.4.3. It MUST NOT
      appear in this extension.
---
   signature
      This field indicates the signature algorithm which may be used.
      The values indicate anonymous signatures, RSASSA-PKCS1-v1_5
|     [PKCS1], and DSA or ECDSA [DSS] respectively.  The "anonymous"
             ^        ^^^^^^^^^
      value is meaningless in this context but used in Section 7.4.3.
      It MUST NOT appear in this extension.

(11c)  missing articles and clarification

For consistency in style and garmmar, I suggest inserting one instance
of "the" in the subsequent paragraph:

   The semantics of this extension are somewhat complicated because the
   cipher suite indicates permissible signature algorithms but not hash
   algorithm. Sections 7.4.2 and 7.4.3 describe the appropriate rules.
---
   The semantics of this extension are somewhat complicated because the
|  cipher suite indicates permissible signature algorithms but not the
                                                                  ^^^^
   hash algorithm.  Sections 7.4.2 and 7.4.3 describe the appropriate
   rules.

Similarly, in the next paragraph I suggest inserting another "the"
and perform another small clarifications:

:      [...]. If the client does not support the default algorithms, or
                 ^^^
   supports other hash and signature algorithms (and it is willing to
|  use them for verifying messages sent by server; server certificates
                                          ^
   and server key exchange), it MUST send the signature_algorithms
|  extension listing the algorithms it is willing to accept.
---         ^
       [...]. If the client does not support the default algorithms, or
   supports other hash and signature algorithms (and it is willing to
|  use them for verifying messages sent by the server, i.e., server
                                           ^^^^      ^^^^^^^
   certificates and server key exchange), it MUST send the
|  signature_algorithms extension, listing the algorithms it is willing
                                 ^^
   to accept.

(11d)  improper use of notation for `struct` constants

According to Section 4.8, constants for `struct` constructe in the
TLS Presentation Language should be enclosed in curly braces.  This
rule is broken in the bulleted list near the end of section 7.4.1.4.1.

For consistency in the notation, therefore please change 3 instances:

   -  If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
   DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent
|  the value (sha1,rsa).
---          ^        ^
   -  If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
   DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent
|  the value {sha1,rsa}.
             ^        ^

   -  If the negotiated key exchange algorithm is one of (DHE_DSS,
|  DH_DSS), behave as if the client had sent the value (sha1,dsa).
---                                                    ^        ^
   -  If the negotiated key exchange algorithm is one of (DHE_DSS,
|  DH_DSS), behave as if the client had sent the value {sha1,dsa}.
                                                       ^        ^

   -  If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
|  ECDHE_ECDSA), behave as if the client had sent value (sha1,ecdsa).
---                                                     ^          ^
   -  If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
|  ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.
                                                        ^          ^

(12)  Section 7.4.2

In the last paragraph of Section 7.4.2, for consistency please also
insert the missing article:

   As cipher suites that specify new key exchange methods are specified
|  for the TLS Protocol, they will imply certificate format and the
   required encoded keying information.
---                                     ^
   As cipher suites that specify new key exchange methods are specified
|  for the TLS Protocol, they will imply the certificate format and the
   required encoded keying information.


(13)  Section 7.4.3

(13a)  'hooks' for ECDH missing

It strikes that, unlike other preceding and subsequent sections, this
section does not provide the fundamental `hooks` for extensibility,
in particular the use of Elliptic Curve Cryptography with TLS
(RFC 4492 [TLSECC], see also Appendix A.7).

At a minimum, I suggest to ...

-  add a note referring to [TLSECC] for the ECC key exchange
   methods (ECDH_*) to the initial prose of the section;

-  amend the presentation language definition of the enumerated
   type KeyExchangeAlgorithm by a related comment:

|     enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa }
           KeyExchangeAlgorithm;
---                                                        ^
|     enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa
|            /* may be extended, e.g. for ECDH -- see [TLSECC] */
|          }
           KeyExchangeAlgorithm;

-  amend the presentation language definition of
   struct ServerKeyExchange by a related comment:

      struct {
          select (KeyExchangeAlgorithm) {
              case dh_anon:
                  ServerDHParams params;
              case dhe_dss:
              [...]
              case dh_rsa:
                  struct {} ;
                 /* message is omitted for rsa, dh_dss, and dh_rsa */
|         };
      } ServerKeyExchange;
---
      struct {
          select (KeyExchangeAlgorithm) {
              case dh_anon:
                  ServerDHParams params;
              case dhe_dss:
              [...]
              case dh_rsa:
                  struct {} ;
                 /* message is omitted for rsa, dh_dss, and dh_rsa */
|             /* may be extended, e.g. for ecdh_* -- see [TLSECC] */
|         };
      } ServerKeyExchange;

(13b)  2nd-to-last paragraph: terminology

As already indicated in item (4) for Section 4.7, I suggest to
precisely distinguish between 'DSA' and 'DSS' in the prose of
the draft, and to more explicitely deal with the scope of the DSS.
I also suggest to consistently use the definite article in front of
both acronyms (in standalone occurrences).

Therefore, I suggest to change and clarify, in the 2nd-to-last
paragraph of Section 7.4.3:

   Because DSA signatures do not contain any secure indication of hash
   algorithm, there is a risk of hash substitution if multiple hashes
|  may be used with any key. Currently, DSS [DSS] may only be used with
|  SHA-1. Future revisions of DSS [DSS-3] are expected to allow other
|  digest algorithms, as well as guidance as to which digest algorithms
   should be used with each key size. In addition, [...]
---
   Because DSA signatures do not contain any secure indication of hash
   algorithm, there is a risk of hash substitution if multiple hashes
|  may be used with any key.  Currently, the DSA [DSS] may only be used
                                    vvvv ^^^^  ^
|  with SHA-1.  Future revisions of the DSS [DSS-3] are expected to
   allow other digest algorithms with all supported signature algorithms
   vvvvvvvvvvvvvvvvvvvvv        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|  (DSA, RSA, and ECDSA), as well as guidance as to which digest
   algorithms should be used with each key size.  In addition, [...]


(14)  Section 7.4.5

For clarity and conformance with preferred RFC-Editor style,
I suggest adding a comma in the 2nd paragraph of the
"Meaning of this message" clause:

      Upon receipt of the server hello done message, the client SHOULD
|     verify that the server provided a valid certificate, if required
      and check that the server hello parameters are acceptable.
---                                                                   ^
      Upon receipt of the server hello done message, the client SHOULD
|     verify that the server provided a valid certificate, if required,
      and check that the server hello parameters are acceptable.


(15)  Section 7.4.6, "Meaning of this message" clause

(15a)
For clarity and consistency in the grammar, I suggest to slightly
modify the 1st paragraph:

      This message conveys the client's certificate chain to the server;
:     the server will use it when verifying the certificate verify
                             ^^^^^^^^^^^^^^
|     message (when the client authentication is based on signing), or
                                                                  ^^^^
|     calculate the premaster secret (for non-ephemeral Diffie-Hellman).
---           ^
      This message conveys the client's certificate chain to the server;
      the server will use it when verifying the certificate verify
|     message (when the client authentication is based on signing) or
|     calculating the premaster secret (for non-ephemeral Diffie-
      Hellman).

(15b)
Also for consistency in style/grammar, I suggest to add a missing
article in the last sub-item of the second bullet:

      rsa_fixed_ecdh      ECDH-capable public key; MUST use
      ecdsa_fixed_ecdh    the same curve as server's key, and
                          MUST use a point format supported by
                          the server.
---
      rsa_fixed_ecdh      ECDH-capable public key; MUST use the
|     ecdsa_fixed_ecdh    same curve as the server's key, and
                          MUST use a point format supported by
                          the server.

(Line folding also 'flattened' a bit for enhanced optics)


(16)  Section 7.4.7 -- typo

In the first line of the "Meaning of this message" clause, please

          s/either though/either through/


(17)  Section 7.4.7.1

(17a)  paragraph between the two "Note"s

To disambiguate the text regarding the differences between 'plain' and
'encoded' TLS versions, I suggest to change pure "1.0" to "TLS 1.0":

   Client implementations MUST always send the correct version number in
:  PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher,
                                                     ^^^^^^^
   server implementations MUST check the version number as described in
|  the note below. If the version number is 1.0 or earlier, server
                                            ^^^
   implementations SHOULD check the version number, but MAY have a
   configuration option to disable the check. [...]
---
   Client implementations MUST always send the correct version number in
   PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher,
   server implementations MUST check the version number as described in
|  the note below. If the version number is TLS 1.0 or earlier, server
                                            ^^^^
   implementations SHOULD check the version number, but MAY have a
   configuration option to disable the check. [...]

(17b)  subsequent enumerated list

To avoid confusion between the encrypted and the plaintex version
of the message, I suggest changing item 2. of the subsequent list:

      2. Decrypt the message M

      3. If the PKCS#1 padding is not correct, or the length of
         message M is not exactly 48 bytes:
           [...]
---
|     2. Decrypt the message to recover the plaintext M
                            ^^^^^^^^^^^^^^^^^^^^^^^^^
      3. If the PKCS#1 padding is not correct, or the length of
         message M is not exactly 48 bytes:
           [...]

(17c)  spurious word replication

Near the end of the 4th paragraph below the numbered list (i.e., the
first "Implementation Note, or the 3nd-to-last paragraph of section
7.4.7.1), please correct the spurious replication of "the":

           /the the length bytes/the length bytes/
                ^^^^

(18)  Section 7.4.8, last paragraph

Please apply the change recommended in item (13b) above, again:

      Because DSA signatures do not contain any secure indication of
      hash algorithm, there is a risk of hash substitution if multiple
      hashes may be used with any key. Currently, DSS [DSS] may only be
      used with SHA-1. Future revisions of DSS [DSS-3] are expected to
      allow other digest algorithms, as well as guidance as to which
      digest algorithms should be used with each key size. [...]

      Because DSA signatures do not contain any secure indication of
      hash algorithm, there is a risk of hash substitution if multiple
|     hashes may be used with any key.  Currently, the DSA [DSS] may
|     only be used with SHA-1.  Future revisions of the DSS [DSS-3] are
|     expected to allow other digest algorithms for all supported
|     signature algorithms (DSA, RSA, and ECDSA), as well as guidance as
      to which digest algorithms should be used with each key size.
      [...]


(19)  Section 7.4.9, "Meaning of the Message" clause

I suggest the following clarification, and to delete a hyphen:

      The finished message is the first protected with the just-
      negotiated algorithms, keys, and secrets. [...]
---                                     vvvv                   ^   v
|     The finished message is the first one protected with the just
      negotiated algorithms, keys, and secrets.  [...]


(20)  Section 12

In the middle bulleted 'list' (of only a single item), the trailing
period is missing:

   -  TLS ExtensionType Registry: Future values are allocated via IETF
|     Consensus [RFC2434]
---                      ^
   -  TLS ExtensionType Registry: Future values are allocated via IETF
|     Consensus [RFC2434].
                         ^


(21)   Appendix A

To accommodate the true content of the appendix and not misguide
the reader, I suggest amending the title of the appendix:

 Appendix A. Protocol Constant Values
---
 Appendix A. Protocol Data Structures and Constant Values
                      ^^^^^^^^^^^^^^^^^^^^


(22)  Appendix A.4.1

(22a)  HashAlgorithm

As indicated in item (11a) above, I strongly recommend to provide
the immediate assignment of a codepoint for SHA-224 (this change
needs to be synchronized with Section 7.4.1.4):

   enum{
       none(0), md5(1), sha1(2), sha256(3), sha384(4),
       sha512(5), (255)
   } HashAlgorithm;
---
   enum {
|      none(0), md5(1), sha1(2), sha224(TBA), sha256(3), sha384(4),
       sha512(5), (255)
   } HashAlgorithm;
                                 ^^^^^^^^^^^^^

(22b)  SignatureAlgorithm -- inconsistency / code point missing

For consistency with Section 7.4.1.4, as quoted in item (11b) above,
the missing code point for ecdsa needs to be supplied here as well:

   enum { anonymous(0), rsa(1), dsa(2), (255) } SignatureAlgorithm;
---
|  enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
|     SignatureAlgorithm;


(23)  Appendix A.4.2

As noted above in item (13a), I strongly suggest to make the `hooks`
for Elliptic Curve Cryptography with TLS more (and more consistently)
visible.

Therefore, I recommend to also amend the copies of the presentation
language definitions of

     enum KeyExchangeAlgorithm
and
     struct ServerKeyExchange

repeated here by a the comments proposed in item (13a) above.


(24)  Appendix A.5

(24a)  textual enhancements for paragraph below TLS_RSA_* table

There's a replicated "a", and the phrase "DHE parameter" might be
considered confusing / ambiguous.  I suggest the textual improvement:

   [...] DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
|  parameters are signed by a a signature-capable certificate, which has
                            ^^^
   been signed by the CA. The signing algorithm used by the server is
|  specified after the DHE parameter.  [...]
---                    ^^^^^^^^^^^^^
   [...] DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
|  parameters are signed by a signature-capable certificate, which has
   been signed by the CA. The signing algorithm used by the server is
|  specified after the DHE name component of the Ciphersuite designation.
   [...]
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

(24b)  TLS_DH* tables

I recommend to always use the same spelling of the Ciphersuite
constants, with no space after the comma and a single space in front
of the trailing "}", not only for the legacy code points, but also
for the new ones, "TBDx".

Thus, please enhance the presentation as follows:

      [...]
      CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA      = { 0x00,0x38 };
      CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA      = { 0x00,0x39 };
|     CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256    = { 0x00, TBD4};
|     CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256    = { 0x00, TBD5};
|     CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256   = { 0x00, TBD6};
|     CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256   = { 0x00, TBD7};
|     CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256    = { 0x00, TBD8};
|     CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256    = { 0x00, TBD9};
|     CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256   = { 0x00, TBDA};
|     CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256   = { 0x00, TBDB};
---                                                             ^^    ^
      [...]
      CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA      = { 0x00,0x38 };
      CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA      = { 0x00,0x39 };
|     CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256    = { 0x00,TBD4 };
|     CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256    = { 0x00,TBD5 };
|     CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256   = { 0x00,TBD6 };
|     CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256   = { 0x00,TBD7 };
|     CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256    = { 0x00,TBD8 };
|     CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256    = { 0x00,TBD9 };
|     CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256   = { 0x00,TBDA };
|     CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256   = { 0x00,TBDB };
                                                                ^    ^^
and:

      CipherSuite TLS_DH_anon_WITH_RC4_128_MD5          = { 0x00,0x18 };
      CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x1B };
      CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA      = { 0x00,0x34 };
      CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA      = { 0x00,0x3A };
|     CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256   = { 0x00, TBDC};
|     CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256   = { 0x00, TBDD};
---                                                             ^^    ^
      CipherSuite TLS_DH_anon_WITH_RC4_128_MD5          = { 0x00,0x18 };
      CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x1B };
      CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA      = { 0x00,0x34 };
      CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA      = { 0x00,0x3A };
|     CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256   = { 0x00,TBDC };
|     CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256   = { 0x00,TBDD };
                                                                ^    ^^

(24c)  last long paragraph

Please consider adding two instances of the indefinite article:

   Note that using non-anonymous key exchange without actually verifying
   the key exchange is essentially equivalent to anonymous key exchange,
   and the same precautions apply.  [...]
---                vv
|  Note that using a non-anonymous key exchange without actually
|  verifying the key exchange is essentially equivalent to an anonymous
   key exchange, and the same precautions apply.  [...]
                                                           ^^^
(change might be replicated subsequently)


(25)  Appendix A.6

As in Section 6.1 (item (5) of first part of this review), the
extended algorithm agility should be indicated for PRFAlgorithm
as well, in the presentation language comment:

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


(26)  Appendix B

(26a)   placement of ref. tags, hyphenation

Occasionally, in this Appendix ref. tags are placed behind the
trailing period of a sentence.  This may be acceptable if done
 at the end of an entry, but it is confusing in its middle.
Thus, at a minimum, please change, e.g., (this proposal also
incorporates the placement of four hyphens in attribute-like
number/word combinations):

   Advanced Encryption Standard (AES)
      AES is a widely used symmetric encryption algorithm.  AES is a
      block cipher with a 128, 192, or 256 bit keys and a 16 byte block
|     size. [AES] TLS currently only supports the 128 and 256 bit key
      sizes.
---       ^^^^^^^^^
   Advanced Encryption Standard (AES)
|     AES [AES] is a widely used symmetric encryption algorithm.  AES is
      a block cipher with a 128, 192, or 256-bit keys and a 16-byte
      block size.  TLS currently only supports the 128- and 256-bit key
      sizes.

(26b)  update/clarification

There are several placed, where the definitions in Appendix B are
outdated and should be adapted to current knowledge/practice.

For instance:

   block cipher
      A block cipher is an algorithm that operates on plaintext in
|     groups of bits, called blocks. 64 bits is a common block size.
---
   block cipher
      A block cipher is an algorithm that operates on plaintext in
|     groups of bits, called blocks. 64 bits was, and 128 bits is,
      a common block size.

(26c)  update/clarification (plus hyphenation)

Second instance:

   Data Encryption Standard
      DES is a very widely used symmetric encryption algorithm. DES is a
      block cipher with a 56 bit key and an 8 byte block size. Note that
      in TLS, for key generation purposes, DES is treated as having an 8
      byte key length (64 bits), but it still only provides 56 bits of
      protection. (The low bit of each key byte is presumed to be set to
      produce odd parity in that key byte.) DES can also be operated in
      a mode where three independent keys and three encryptions are used
      for each block of data; this uses 168 bits of key (24 bytes in the
      TLS key generation method) and provides the equivalent of 112 bits
      of security. [DES], [3DES]
---
   Data Encryption Standard
|     DES still is a very widely used symmetric encryption algorithm,
          ^^^^^^                                                    ^
|     although it is generally considered as rather weak now.  DES is a
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|     block cipher with a 56-bit key and an 8-byte block size. Note that
                            ^                ^
      in TLS, for key generation purposes, DES is treated as having an
|     8-byte key length (64 bits), but it still only provides 56 bits of
       ^
      protection. (The low bit of each key byte is presumed to be set to
      produce odd parity in that key byte.) DES can also be operated in
      a mode where three independent keys and three encryptions are used
      for each block of data; this uses 168 bits of key (24 bytes in the
      TLS key generation method) and provides the equivalent of 112 bits
      of security. [DES], [3DES]

(26d)  update

   Digital Signature Standard (DSS)
      A standard for digital signing, including the Digital Signing
      Algorithm, approved by the National Institute of Standards and
|     Technology, defined in NIST FIPS PUB 186, "Digital Signature
|     Standard", published May, 1994 by the U.S. Dept. of Commerce.
|     [DSS]
   Digital Signature Standard (DSS)
      A standard for digital signing, including the Digital Signing
      Algorithm, approved by the National Institute of Standards and
|     Technology, defined in NIST FIPS PUB 186-2, "Digital Signature
                           vvvvvvvvvvvvv      ^^
      Standard", published January, 2000 by the U.S. Dept. of Commerce
|     [DSS].  A significant update has been drafted and published in
|     March 2006.  DSS-3]

(26e)  update/clarification
               vvvvvvv
   MD5
|     MD5 is a secure hashing function that converts an arbitrarily long
      data stream into a hash of fixed size (16 bytes). [MD5]
---
   MD5
|     MD5 is a hashing function that converts an arbitrarily long data
|     stream into a hash of fixed size (16 bytes).  Due to significant
|     progresses in cryptanalysis, at the time of publication of this
|     document, MD5 no longer can be considered a 'secure' hashing
|     function.  [MD5]

(26f)  update/clarification

   SHA
      The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
      produces a 20-byte output. Note that all references to SHA
      actually use the modified SHA-1 algorithm. [SHA]
---
   SHA
      The Secure Hash Algorithm is defined in FIPS PUB 180-2.  It
      produces a 20-byte output.  Note that all references to SHA
|     (without a numerical suffix) actually designate the SHA-1
|     algorithm.  [SHS]


(27)  Appendix C

(27a)  "Expanded Key Material"

Do we really still need this column in the second table ?

It was only significant for historical encryption algorithms now
considered to weak to be practically useful and hence no more listed
in the current version of this table; all current entries are equal
to the corresponding entries in the "Key Material" column.

(27b)  columnar alignment

I suggest to strictly use decimal alignment in the numerical
columns of the second and the third table in Appendix C.

Should the conclusion be made to retain the "Expanded Key Material"
column in the second table, it might be improved to this more
pleasant layout:

                      Key      Expanded     IV    Block
 Cipher       Type  Material Key Material   Size   Size

 NULL         Stream   0          0         0     N/A
 RC4_128      Stream  16         16         0     N/A
 3DES_EDE_CBC Block   24         24         8      8
 AES_128_CBC  Block   16         16         16    16
 AES_256_CBC  Block   32         32         16    16
---
|                          Key       Expanded      IV   Block
|  Cipher        Type    Material  Key Material   Size  Size
|  ------------  ------  --------  ------------   ----  -----
|  NULL          Stream      0           0          0    N/A
|  RC4_128       Stream     16          16          0    N/A
|  3DES_EDE_CBC  Block      24          24          8      8
|  AES_128_CBC   Block      16          16         16     16
|  AES_256_CBC   Block      32          32         16     16

otherwise, it could be simplified as:

|                             Key      IV   Block
|     Cipher        Type    Material  Size  Size
|     ------------  ------  --------  ----  -----
|     NULL          Stream      0       0    N/A
|     RC4_128       Stream     16       0    N/A
|     3DES_EDE_CBC  Block      24       8      8
|     AES_128_CBC   Block      16      16     16
|     AES_256_CBC   Block      32      16     16

Similarly, the third table should be facelifted as:

 MAC       Algorithm    mac_length  mac_key_length

 NULL      N/A          0           0
 MD5       HMAC-MD5     16          16
 SHA       HMAC-SHA1    20          20
 SHA256    HMAC-SHA256  32          32
---
|     MAC       Algorithm    mac_length  mac_key_length
|     --------  -----------  ----------  --------------
|     NULL      N/A              0             0
|     MD5       HMAC-MD5        16            16
|     SHA       HMAC-SHA1       20            20
|     SHA256    HMAC-SHA256     32            32


(28)  Appendix E.1 -- textual improvements

(28a)  6th paragraph
                                                         v
|  A TLS server can also receive a ClientHello containing version number
   smaller than the highest supported version. If the server wishes to
   negotiate with old clients, it will proceed as appropriate for the
   highest version supported by the server that is not greater than
   ClientHello.client_version. For example, if the server supports TLS
   1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
|  proceed with a TLS 1.0 ServerHello. If server supports (or is willing
                                         ^
   to use) only versions greater than client_version, it MUST send a
   "protocol_version" alert message and close the connection.
---                                                      vvv
|  A TLS server can also receive a ClientHello containing a version
   number smaller than the highest supported version.  If the server
   wishes to negotiate with old clients, it will proceed as appropriate
   for the highest version supported by the server that is not greater
   than ClientHello.client_version.  For example, if the server supports
   TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
|  proceed with a TLS 1.0 ServerHello.  If the server supports (or is
                                          ^^^^^
   willing to use) only versions greater than client_version, it MUST
   send a "protocol_version" alert message and close the connection.

(28b)  7th paragraph
                                                       v
|  Whenever a client already knows the highest protocol known to a
   server (for example, when resuming a session), it SHOULD initiate the
   connection in that native protocol.
---                                                    vvvvvvvvv
|  Whenever a client already knows the highest protocol version known to
   a server (for example, when resuming a session), it SHOULD initiate
   the connection in that native protocol.

(28c)  8th paragraph

   Note: some server implementations are known to implement version
   negotiation incorrectly. For example, there are buggy TLS 1.0 servers
   that simply close the connection when the client offers a version
   newer than TLS 1.0. Also, it is known that some servers will refuse
|  connection if any TLS extensions are included in ClientHello.
   [...]
---
   Note: some server implementations are known to implement version
   negotiation incorrectly. For example, there are buggy TLS 1.0 servers
   that simply close the connection when the client offers a version
   newer than TLS 1.0. Also, it is known that some servers will refuse
|  the connection if any TLS extensions are included in ClientHello.
   ^^^^
   [...]


(29)  References

(29a)  demote [DES] to Informative -- due to lack of Historical  :-)

Rationale:  FIPS PUB 46-3 has been formally withdrawn May 19, 2005.


(29b)  rational quotation

For the entries
    [DSS] , [SHA] , [DSS-3] , [PKCS6] , [PKCS7] , [RSA] , and [TCP]

     s/,"/",/

(29c)  SHS

I strongly suggest to rename the ref. tag '[SHA]' to '[SHS]', for the
sake of terminological consistency.  Also, the publication date should
be updated to account for the Change Note adding SHA-224 support.
Finally, there's spurious punctuation.

Incorporating all proposed changes:
      v                                               vv
   [SHA]    NIST FIPS PUB 180-2, "Secure Hash Standard," National
            Institute of Standards and Technology, U.S. Department of
            Commerce., August 2001.
---   v             ^^           ^                    vv
|  [SHS]    NIST FIPS PUB 180-2, "Secure Hash Standard", National
            Institute of Standards and Technology, U.S. Department of
            Commerce, August 2002.
                    ^            ^

(29d)  update

[AEAD]  has been publised as RFC 5116, January 2008.



Ooouuuggghhh!   That's it.

Kind regards,
  Alfred.

-- 

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