[TLS] draft-badra-tls-password-ext-01

[Alfred Hönes <ah at tr-sys.de>]

Hello,
after studying the Internet-Draft authored/edited by you,
                draft-badra-tls-password-ext-01,
I'd like to submit a few comments.


(0)  General

For pedagogical reasons regarding the handling of secrets,
I suggest to generally replace the word "password" by "passphrase",
thus (hopefully) encouraging readers to support secrets with
reasonable entropy.
This should be done everywhere in the text, including its title,
and the name of the extension and its fields.

In places where text affected by this change needs to be quoted
below for other reasons, I have performed this change, but I have
omitted listing all occurrences, for brevity.


(1)  Section 2

(1a)  2nd paragraph

I suggest to simplify the text to improve the readability and avoid
the grammar conflict present currently:

|  For servers aware of the password extension but not wishing to use
|  it, it will gracefully revert to an ordinary TLS handshake or stop
   the negotiation.
---vv                                                                vv
|  A server aware of the password extension but not wishing to use it
|  will gracefully revert to an ordinary TLS handshake or stop the
   negotiation.

(1b)  3rd paragraph

Note that it apparently is intended to only use a single password/
passphrase per TLS handshake.  To disambiguate this, I suggest to
use singular and also talk about 'a server'.  Further, the last
sentence, in its unqualified form, is misleading (after the "MAY");
it needs the proper predicate.

|  Servers that receive an extended hello containing a "password"
|  extension MAY agree to authenticate the client using passwords by
|  including an extension of type "password", with empty
|  "extension_data", in the extended server hello.  The
   CertificateRequest payload is omitted from the server response.
---vvv                  v
|  A server that receives an extended hello containing a "passphrase"
|  extension MAY agree to authenticate the client using a passphrase by
                                       vvvvvv           ^^^^^^^^^^^^
|  including an extension of type "passphrase", with empty
|  "extension_data", in the extended server hello.  In this case, the
                                                    ^^^^^^^^^^^^^^^
   CertificateRequest payload is omitted from the server response.

(1c)  4th paragraph

Please correct the typo, and also add the proper predicate to
disambiguate the requirements stated in the rest of the section:
                                                                     vv
   Clients return a response along with their credentials by sending a
   "EncryptedPassword" message immediately after the "ClientKeyExchange"
   message.  [...]
---
|  If the use of the "passphrase" extension has been negotiated this way,
|  the following rules apply:
|
|  The client returns a response along with his credentials by sending
   ^^^^^     ^      ^
|  an "EncryptedPassphrase" message immediately after the
   ^^^              ^^^^^^
   "ClientKeyExchange" message.  [...]


(2)  Section 2.1

(2a)
Apply (0) above throughout!

(2b)  "Structure of the message"

Fix the typo:
                     uint8 adding[EncryptedPassword.padding_length];
---
|                    uint8 padding[EncryptedPassphrase.padding_length];
                           ^                    ......

(2c)  1st para below message structure + field explanations

Please clarify
(*deployment* of the feature does not matter, *use* does!):

|  BulkCipherAlgorithm.null (e.g.  TLS_RSA_WITH_NULL_MD5 and
|  RSA_WITH_NULL_SHA) MUST NOT be negotiated when password extension is
|  deployed, as it provides no more protection than an unsecured
   connection.
---
|  BulkCipherAlgorithm.null (e.g., TLS_RSA_WITH_NULL_MD5 and
                                 ^
|  RSA_WITH_NULL_SHA) MUST NOT be negotiated when the passphrase
                                                          ^^^^^^
|  extension is used, as it would provide no more protection than an
                ^^^^        ^^^^^^      ^^
   unsecured connection.

(2d)  second-to-last text paragraph -- textual improvement

   Next, the server will then check the authentication database to see
|  if the received username/password and those stored in the database
   match.  If a match is found, the server sends its change cipher spec
|  message and proceeds directly to finished message.  If no match is
|  found, the server MUST send a fatal alert, results in the immediate
   termination of the connection.
---
   Next, the server will then check the authentication database to see
|  if the received username/passphrase and those stored in the database
                                ^^^^^^
   match.  If a match is found, the server sends its change cipher spec
|  message and proceeds directly to the Finished message.  If no match
                                    ^^^^^
|  is found, the server MUST send a fatal alert, which results in the
                                                 ^^^^^^
   immediate termination of the connection.

(2e)  last text paragraph

RADIUS (still) is the most widely used AAA protocol.
Hence; the text better should not talk about "AAA or RADIUS";
I suggest to simply use "AAA" instead.


(3)  Section 3.1

Arguably, this section deals with the *user* interface.

Furthermore, for every instance of a TLS hanshake using the
extension, only a single username/passphrase combination is needed.
Therefore, I recommend strictly using singular:
                  v       vvv
|     o   Entering usernames consisting of up to 128 printable Unicode
          characters.

|     o   Entering passwords up to 64 octets in length as ASCII strings
          vvv     ^    ^^^^^^               vvvvvvvvvv
|         and in hexadecimal encoding.  The management interface MAY
          accept other encodings if the algorithm for translating the
          encoding to a binary string is specified.
---               vvv       vv
      o   Entering a username consisting of up to 128 printable Unicode
          characters.
      o   Entering a passphrase of up to 64 octets in length as ASCII
                  ^^^    ^^^^^^^^^^
|         strings or in hexadecimal encoding.  The user interface MAY
                  ^^                               ^^^^
          accept other encodings if the algorithm for translating the
          encoding to a binary string is specified.

BTW: Why only 64 octets?

Furthermore, I strongly recommend to set requirements to ensure
a minimum entropy of the passphrase.  A simple rule (suitable for
being checked easily by humans), might be:

   The passphrase SHOULD at least contain 16 different octets, and at
   least 16 octets (say, x) in the passphrase must have neighbor octets
   not contained in the set {x-1, x, x+1} (mod 256).

(The latter part aims at excluding long 'runs' of ascending/descending
sequences.)


(4)  Sections 4 through 6

When the ref. to RFC 4346 is updated to 4346bis, there's no more
need to also refer to RFC 4366 (or 4366bis), because 4346bis has
incorporated the Hello extension framework and the draft does not
make any use of the particular extensions documented in RFC 4366 /
4366bis.

Doing so, in particular the following changes apply:

(4a)  Section 4

   The security considerations described throughout [RFC4346] and
   [RFC4366] apply here as well.
---
|  The security considerations described throughout [4346bis] apply here
   as well.

(4b)  Section 5

   This document defines a new TLS extension "password", assigned the
   value to be allocated from the TLS ExtensionType registry defined in
   [RFC4366].
---                                                               v
|  This document defines a new TLS extension "password", assigned a
   value to be allocated from the TLS ExtensionType registry defined in
|  [4346bis].


Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah at TR-Sys.de                     |
+------------------------+--------------------------------------------+

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