Re: [TLS] "Last call" on draft-altman-tls-channel-bindings-05.txt

Nicolas Williams <Nicolas.Williams@sun.com> Wed, 19 August 2009 22:33 UTC

Return-Path: <Nicolas.Williams@sun.com>
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 673CC3A6A6A for <tls@core3.amsl.com>; Wed, 19 Aug 2009 15:33:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.905
X-Spam-Level:
X-Spam-Status: No, score=-5.905 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 Uo2OdIg-rQTz for <tls@core3.amsl.com>; Wed, 19 Aug 2009 15:33:19 -0700 (PDT)
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 1A5BB3A69DE for <tls@ietf.org>; Wed, 19 Aug 2009 15:33:07 -0700 (PDT)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7JMXCbQ003220 for <tls@ietf.org>; Wed, 19 Aug 2009 22:33:12 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n7JMXBRx058469 for <tls@ietf.org>; Wed, 19 Aug 2009 16:33:11 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7JMMU9U004576; Wed, 19 Aug 2009 17:22:30 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7JMMUYM004575; Wed, 19 Aug 2009 17:22:30 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Wed, 19 Aug 2009 17:22:29 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Simon Josefsson <simon@josefsson.org>
Message-ID: <20090819222229.GS1043@Sun.COM>
References: <20090818213427.GU1043@Sun.COM> <87ljlgbv2a.fsf@mocca.josefsson.org> <20090819212223.GN1043@Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20090819212223.GN1043@Sun.COM>
User-Agent: Mutt/1.5.7i
Cc: ietf-sasl@imc.org, tls@ietf.org
Subject: Re: [TLS] "Last call" on draft-altman-tls-channel-bindings-05.txt
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-Archive: <http://www.ietf.org/mail-archive/web/tls>
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>
X-List-Received-Date: Wed, 19 Aug 2009 22:33:20 -0000

On Wed, Aug 19, 2009 at 04:22:24PM -0500, Nicolas Williams wrote:
> On Wed, Aug 19, 2009 at 12:45:17AM +0200, Simon Josefsson wrote:
> > For completeness, I would add:
> > 
> >    This algorithm agility resolution mechanism assumes that there is a
> >    mapping from every Public-key signature algorithm to one hash
> >    function algorithm.  This is the case for all practically used public
> >    key signature algorithms today, but if future public-key signature
> >    algorithms would employ multiple hash functions (or none at all) this
> >    specification needs to be updated to resolve which hash function
> >    should be used.
> 
> This brings up a question: what to do in the case of randomized digital
> signatures?  In the case of NIST-SP-800-106 there's still a hash
> function, so that's OK.  But one can imagine a digital signature
> algorithm where a MAC and random key are used instead of a hash.
> 
> ...
> 
> But I don't want to guess at what might happen in the future
> of digital signatures.  Instead I'd rather either say either
> that tls-server-end-point CB is undefined if the cert's
> signature alg does not use a signature, or pick a hash
> function (e.g., SHA-512) to use in such cases.

After asking others I propose the former solution:

   Description: The hash of the TLS server's certificate [RFC5280] as it
   appears, octet for octet, in the server's Certificate message (note
   that the Certificate message contains a certificate_list, the first
   element of which is the server's certificate.)

   The hash function is to be selected as follows:

    - if the certificate's signatureAlgorithm uses a single hash
      function, and that hash function is either MD5 [RFC1321] or SHA-1
      [RFC3174] then use SHA-256 [FIPS-180-2];

    - if the certificate's signatureAlgorithm uses a single hash
      function and that hash function neither MD5 nor SHA-1, then use
      the hash function associated with the certificate's
      signatureAlgorithm;

    - if the certificate's signatureAlgorithm uses no hash functions, or
      multiple hash functions, then this channel binding type's channel
      bindings are undefined at this time (updates to is channel binding
      type may occur to address this issue if it ever arises).

Nico
--