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

Nicolas Williams <Nicolas.Williams@sun.com> Wed, 19 August 2009 16:28 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 2B1A23A6D6A for <tls@core3.amsl.com>; Wed, 19 Aug 2009 09:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.921
X-Spam-Level:
X-Spam-Status: No, score=-5.921 tagged_above=-999 required=5 tests=[AWL=0.125, 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 7bTuJpouz6wT for <tls@core3.amsl.com>; Wed, 19 Aug 2009 09:28:30 -0700 (PDT)
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 986D73A6A3C for <tls@ietf.org>; Wed, 19 Aug 2009 09:28:18 -0700 (PDT)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7JGSKVG023035 for <tls@ietf.org>; Wed, 19 Aug 2009 16:28:20 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n7JGSJpP038642 for <tls@ietf.org>; Wed, 19 Aug 2009 10:28:19 -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 n7JGHXVB004013; Wed, 19 Aug 2009 11:17:33 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7JGHSpp004012; Wed, 19 Aug 2009 11:17:28 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Wed, 19 Aug 2009 11:17:28 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Simon Josefsson <simon@josefsson.org>
Message-ID: <20090819161728.GB1043@Sun.COM>
References: <20090818213427.GU1043@Sun.COM> <87ljlgbv2a.fsf@mocca.josefsson.org> <20090818225934.GW1043@Sun.COM> <87bpmcbqxd.fsf@mocca.josefsson.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87bpmcbqxd.fsf@mocca.josefsson.org>
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 16:28:31 -0000

On Wed, Aug 19, 2009 at 02:14:38AM +0200, Simon Josefsson wrote:
> Nicolas Williams <Nicolas.Williams@sun.com> writes:
> >    Description: ...
> 
> Looks fine to me.
> 
> > The text you quote is security considerations text; the normative text
> > already says exactly what you ask for.  But OK:
> >
> >         ...  The algorithm to be used, however, is derived from the
> >    certificate's signature as described in Section 4.1; to recap: use
> >    SHA-256 if the certificate signature algorithm uses MD5 or SHA-1,
> >    else use whatever hash function the certificate uses.
> 
> There were two uses of "uses" in the sentence, and the second is still
> present, but at least this is better than before.

Ah yes:

        ...  The algorithm to be used, however, is derived from the
   certificate's signature as described in Section 4.1; to recap: use
   SHA-256 if the certificate signature algorithm uses MD5 or SHA-1,
   else use whatever hash function the certificate signature algorithm
   uses.

> > Now, section 4.1 says "if the certificate's signature hash algorithm is
> > ...".  But perhaps it should say "if the hash algorithm used in the
> > certificate's signatureAlgorithm is ...", just to be really accurate and
> > avoid any possible confusion (with, say, the algorithm field of
> > SubjectPublicKeyInfo).  Yes?
> 
> The more precise the better, although SubjectPublicKeyInfo generally do
> not imply any particular hash function.  But for new implementers, it is
> easy to go wrong if the text is not specific.

So let's add that precision and address signature algs that don't use
hash functions:

   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 hash algorithm used in the
   certificate's signatureAlgorithm is either MD5 [RFC1321] or SHA-1
   [RFC3174] or if the certificate's signatureAlgorithm does not use any
   hash functions, then use SHA-256 [FIPS-180-2], otherwise use whatever
   hash algorithm is used by the certificate's signatureAlgorithm.

Nico
--