[TLS] draft-ietf-tls-rfc4366-bis-02

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

Hello,
after studying the Internet-Draft authored/edited by you,
                draft-ietf-tls-rfc4366-bis-02,
I'd like to submit a few comments.


(1)  General:  Hash Algorithm agility

4346bis introduces hash algorithm agility in a pervasive manner
into TLS 1.2, and it has shifted from SHA-1 to SHA-256 as the
basic required hash algorithm.
This draft, considered a companion to 4346bis (and hopefully to be
published with it in a coordinated manner, to avoid confusion about
the state of RFC 4366!), is stuck with SHA-1.

IMO, it should be considered to not only copy the information from
RFC 4366 into this draft, but instead also proactively introduce
hash algorithm agility into the extensions making use of hashes.

Below, I give an rough example (for section 5) of how that could
be done in a backward-compatible manner.


(2)  General:  STD 66 terminology

I suggest to reconsider the use of "URI" vs. "URL" throughout
this draft, for conformance with Section 1.1.3 of RFC 3986.
In particular, the use of "URL scheme" should be avoided in
favor of "URI scheme".

Also, section 4 of STD 66 should be taken into account.

I'll give some detailed change proposals below to exemplify that.


(3)  Section 5

(3a)  Syntax evolution for hash alg. agility

Hash algorithm agility could be introduced into the
"Client Certificate ULR" extension in the following manner,
which (hopefully) is backward compatible as far as possible,
by performing the following changes:

      enum {
|         false(0), true(1)
|     } Boolean;
---
      enum {
|         absent(0), implicitsha1(1), explicit(2)
|     } HashType;


      struct {
          opaque url<1..2^16-1>;
|         Boolean hash_present;
          select (hash_present) {
|             case false: struct {};
|             case true: SHA1Hash;
          } hash;
      } URLAndOptionalHash;
---
      struct {
          opaque url<1..2^16-1>;
|         HashType hash_present;
          select (hash_present) {
|             case absent: struct {};
|             case implicitsha1: SHA1Hash;
|             case explicit: ExplicitHash;
          } hash;
      } URLAndOptionalHash;
|
|     struct {
|         HashAlgorithm hashalg;
|         opaque Hash[hashalg.hashsize];
|     } ExplicitHash;

(This makes use of implicit sizing for Hash, depending on hashalg;
 explicit sizing might be an alternative.
 HashAlgorithm is from 4346bis-09, Section 7.4.1.4.1.)

(3b)  clarification of "URL"

To clarify the intended restrictions (as indicated above), I suggest
to amend the first paragraph below the syntax as follows:

   Here "url_and_hash_list" contains a sequence of URLs and optional
   hashes.
---
   Here "url_and_hash_list" contains a sequence of URLs and optional
   hashes.  Each "url" MUST be an absolute URI reference according to
   [RFC3986] that can be immediately used to fetch the certificate(s).

This change is intended to explicitely exclude relative URI references
and the use of URI schemes that do not lead to "immediate access",
e.g., the 'mailto', 'cid', 'go', or 'tel' URI schemes.

(3c)  ordering of URLs

The paragraph starting,

   Note that when a list of URLs for X.509 certificates is used, the
   ordering of URLs is the same ...

should preferably be more explicit and precisely state the order
required, to improve the readability and not urging the reader
to refer to other documents for this information.
(If deemed necessary, a 'salvatory clause' could be added to the end
of Section 1, for instance:

|  For the ease of the reader, some normative text from [RFCTLS] is
|  restated below.  Any possible deviation from [RFCTLS] has not been
|  intended, and [RFCTLS] shall remain the normative document in such
|  cases.

(3d)  notation of URI schemes

In the second-to-next paragraph in Section 5, I suggest to harmonize
the spelling of, and emphasis (quoting) applied to, URI schemes;
for instance:
                                                       vvvvvvvvvv
|  Servers that support this extension MUST support the http: URL scheme
   for certificate URLs, and MAY support other schemes. Use of other
|  schemes than "http", "https", or "ftp" may create unexpected
   problems.
---             ^    ^  ^     ^     ^   ^
|  Servers that support this extension MUST support the 'http' URI
                                                        ^    ^   ^
   scheme for certificate URLs, and MAY support other schemes.  Use of
|  other schemes than 'http', 'https', or 'ftp' may create unexpected
                      ^    ^  ^     ^     ^   ^
   problems.


(4)  Section 8

Near the end of section 8, two Notes specify the preconditions for
using the Certificate Status Request extension, but unfortunately,
the conditions apparently are incomplete.
I propose to change:

   Note that a server MAY also choose not to send a "CertificateStatus"
|  message, even if it receives a "status_request" extension in the
|  client hello message.

|  Note in addition that servers MUST NOT send the "CertificateStatus"
|  message unless it received a "status_request" extension in the client
|  hello message.
---
   Note that a server MAY also choose not to send a "CertificateStatus"
|  message, even if has received a "status_request" extension in the
|  client hello message and has sent a "status_request" extension in the
|  server hello message.

|  Note in addition that a server MUST NOT send the "CertificateStatus"
   message unless it received a "status_request" extension in the client
|  hello message and sent a "status_request" extension in the server
|  hello message.


(5)  Section 10

IANA should be explicitely requested to re-parent the extensions
registered by RFC 4366 to this document.


(6)  Section 11.3 -- "URI" related clarifications

(6a)  5th paragraph

   The second major issue is that support for client_certificate_url
|  involves the server's acting as a client in another URL protocol.
   The server therefore becomes subject to many of the same security
|  concerns that clients of the URL scheme are subject to, with the
   added concern that the client can attempt to prompt the server to
   connect to some (possibly weird-looking) URL.
---
   The second major issue is that support for client_certificate_url
|  involves the server's acting as a client in another URI scheme
   vvvvvvvvvv                                            ^^^^^^^^
|  dependent protocol.  The server therefore becomes subject to many of
|  the same security concerns that clients of the URI scheme are subject
                                                    ^
   to, with the added concern that the client can attempt to prompt the
   server to connect to some (possibly weird-looking) URL.

(6b)  9th paragraph

-    s/URI protocols/URI schemes/

-    s/set of protocols/set of schemes/


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

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