[TLS] rfc4366-bis-03 Discuss #1: hash alg. agility for CertURLs?

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

The current consensus of the WG has been to leave the definition
of the Client Certificate URLs extension in the rfc4366-bis draft,
and discuss at length the many security considerations related to it.
The -03 draft revision follows this consensus.

Section 5 of the draft contains the following TLS presentation
language definition (from RFC 4366):

---------------------------snip----------------------
      enum {
          individual_certs(0), pkipath(1), (255)
      } CertChainType;

!     enum {
!         false(0), true(1)
!     } Boolean;

      struct {
          CertChainType type;
          URLAndOptionalHash url_and_hash_list<1..2^16-1>;
      } CertificateURL;

      struct {
          opaque url<1..2^16-1>;
!         Boolean hash_present;
!         select (hash_present) {
!             case false: struct {};
!             case true: SHA1Hash;
!         } hash;
      } URLAndOptionalHash;

      opaque SHA1Hash[20];
---------------------------snip----------------------

This WG is tasked by the IESG & IAB to introduce crypto algorithm
agility into the protocols it supports, whereas the above definition
is still restricted to SHA-1 only.

With respect to the strong proviso against using this extension,
it might make sense to only perform the minimum changes to allow
hash algorithm agility to be introduced by a future specification;
the other alternative would be to introduce SHA-256, aligned with
the spirit of TLS v1.2.

Thus, I suggest two variants below, (A) and (B), for consideration.

Both variants are based on a backwards compatible change to the
Boolean hash_present, replacing it by an extensible enum type.

Unfortunately, it is not possible to reuse the HashAlgorithm enum
type from RFC 5246, Section 7.4.1.4.1, without breaking on-the-wire
backwards compatibility with the current use of hash_present.

Existing server implementations are expected to perform strong value
checking on enums and should behave 'gracefully', either returning
an illegal_parameter(47) or an unsupported_extension(110) alert
or ignoring the extension, whenever a 'new' value for the selector
is received.


Variant A: adding hash agility and support for SHA-256
---------

---------------------------snip----------------------
      enum {
          individual_certs(0), pkipath(1), (255)
      } CertChainType;

      enum {
|         none(0), sha1(1), sha256(2), (255)
|     } CertUrlHashType;

      struct {
          CertChainType type;
          URLAndOptionalHash url_and_hash_list<1..2^16-1>;
      } CertificateURL;

      struct {
          opaque url<1..2^16-1>;
|         CertUrlHashType hash_type;
|         select (hash_type) {
|             case none:   struct {};
|             case sha1:   SHA1Hash;
|             case sha256: SHA256Hash;
          } hash;
      } URLAndOptionalHash;

      opaque SHA1Hash[20];
|     opaque SHA256Hash[32];
---------------------------snip----------------------

This variant could be specified as fully applicable to TLS 1.2,
and for previous versions of TLS only with the restriction that
hashtype MUST be 0 or 1.


Variant B: prepare for hash agility only, add no new hash(es)
---------

[This is essentially a restricted version of Variant A.]

---------------------------snip----------------------
      enum {
          individual_certs(0), pkipath(1), (255)
      } CertChainType;

      enum {
|         none(0), sha1(1), (255)
|     } CertUrlHashType;

      struct {
          CertChainType type;
          URLAndOptionalHash url_and_hash_list<1..2^16-1>;
      } CertificateURL;

      struct {
|         CertUrlHashType hash_type;
|         select (hash_type) {
|             case none:   struct {};
|             case sha1:   SHA1Hash;
          } hash;
          opaque url<1..2^16-1>;
      } URLAndOptionalHash;

      opaque SHA1Hash[20];
---------------------------snip----------------------

This variant could be used with all versions of TLS so far.


The draft can proceed in three directions:

(A)  upgrade Section 5 to use Variant A above
     (adding hash agility and support for SHA-256),

(B)  upgrade Section 5 to use Variant B above
     (prepare for hash agility only, add no new hash(es)), or

(C)  leave Section 5 unchanged
     (providing no hash agility).

I fear that (C) might be refused in the IESG because of not
following the direction for support of crypto algorithm agility.


Any opinions?  Further considerations?


Kind regards,
  Alfred.

-- 

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