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

Alfred Hönes <ah@tr-sys.de> Tue, 21 October 2008 19:40 UTC

Return-Path: <tls-bounces@ietf.org>
X-Original-To: tls-archive@ietf.org
Delivered-To: ietfarch-tls-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D02B3A689E; Tue, 21 Oct 2008 12:40:53 -0700 (PDT)
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 174623A689E for <tls@core3.amsl.com>; Tue, 21 Oct 2008 12:40:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.261
X-Spam-Level: *
X-Spam-Status: No, score=1.261 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSU0PYsVEXc5 for <tls@core3.amsl.com>; Tue, 21 Oct 2008 12:40:50 -0700 (PDT)
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id A013C3A6783 for <tls@ietf.org>; Tue, 21 Oct 2008 12:40:49 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA297358044; Tue, 21 Oct 2008 21:40:44 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA27675; Tue, 21 Oct 2008 21:28:59 +0200 (MESZ)
From: Alfred Hönes <ah@tr-sys.de>
Message-Id: <200810211928.VAA27675@TR-Sys.de>
To: tls@ietf.org
Date: Tue, 21 Oct 2008 21:28:58 +0200
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Subject: [TLS] rfc4366-bis-03 Discuss #1: hash alg. agility for CertURLs?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org

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@TR-Sys.de                     |
+------------------------+--------------------------------------------+

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