[TLS] Review comments on draft-rescorla-tls-suiteb-00.txt

[Wan-Teh Chang <wtchang at redhat.com>]

Here are my review comments on the Internet-Draft "SuiteB CipherSuites
for TLS", draft-rescorla-tls-suiteb-00.txt.

1. Nit: throughout the document, some of the "SuiteB" probably should be
changed to "Suite B", and "CipherSuites" be changed to "Cipher Suites"
or "cipher suites".

2. Section 1, the second to last paragraph, "the use of these hash",
change "hash" to "hashes" or "hash algorithms".

Nit: change "SHA256" to "SHA-256" and "SHA384" to "SHA-384".

3. Section 3, the first paragraph says:

  ... the function used for key derivation and data integrity be
  SHA [SHS].

"Fact Sheet NSA Suite B Cryptography" doesn't say anything about
key derivation.  It only says:

  Hashing:     Secure Hash Algorithm - FIPS 180-2
               (using SHA-256 and SHA-384)

The second paragraph says:

  Encryption:  Advanced Encryption Standard (AES)  -
               FIPS 197 with keys sizes of 128 and 256
               bits)

add '(' after "FIPS 197".

4. Section 4. Cipher Suites

I'm curious why you didn't define new counter (CTR) mode cipher suites.

5. Section 5, the second paragraph.

I'm curious why TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 is chosen as
the least common denominator.  In practice it may be less work to add
the new CBC mode cipher suites to existing TLS implementations.

6. Section 5.2, the first paragraph.

In the sentence

  (These are the same curves that appear in FIPS 186-2 and ANSI X9.62
  as P256 and P384, respectively).

remove "and ANSI X9.62",
change "P256" to "P-256" and "P384" to "P-384", and
change ")." to ".)".

ANSI X9.62 calls these curves ansix9p256r1 and ansix9p384r1.

In the sentence

  For cipher suites at the 192-bit security level, secp256r MUST be
  used.

change "secp256r" to "secp384r1".

The last sentence says

  Both uncompressed (0) and ansiX962_compressed_prime(1) point formats
  SHOULD be supported.

Are you sure that ansiX962_compressed_prime(1) point format "SHOULD" be
supported?  RFC 4492 Section 5.1.2 only uses "MAY".

6. Section 5.2, the last paragraph.

The last sentence says

  Clients SHOULD check the chosen curve to make sure it is acceptable.

It seems that we should use "MUST" here.

7. Section 7.2.  Perfect Forward Secrecy

In the last sentence, I suggest changing "mode of operation" to "cipher
suite".

8. Section 7.3.  Counter Reuse with GCM.

In "IV construction algorithm", I suggest changing "IV" to "nonce".

The GCMNonce is defined in Section 4.2 as follows:

             struct {
                case client:
                    uint32 client_write_IV;  // low order 32-bits
                case server:
                    uint32 server_write_IV;  // low order 32-bits
                uint64 seq_num;
             } GCMNonce.

It seems that it's missing "select (...)" around the two cases.

9. Section 10.  References.

The reference [I-D.ietf-tls-ctr] is not being used.  (See my question
in comment 4 above about why this I-D doesn't define new CTR mode
cipher suites.)

Wan-Teh Chang


_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls