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

Simon Josefsson <simon@josefsson.org> Wed, 19 August 2009 00:14 UTC

Return-Path: <simon@josefsson.org>
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 18D293A6BDB for <tls@core3.amsl.com>; Tue, 18 Aug 2009 17:14:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level:
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599]
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 pCkV4Jp4DOWi for <tls@core3.amsl.com>; Tue, 18 Aug 2009 17:14:48 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 098993A6CA8 for <tls@ietf.org>; Tue, 18 Aug 2009 17:14:46 -0700 (PDT)
Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7J0Ect1002404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Aug 2009 02:14:47 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Nicolas Williams <Nicolas.Williams@sun.com>
References: <20090818213427.GU1043@Sun.COM> <87ljlgbv2a.fsf@mocca.josefsson.org> <20090818225934.GW1043@Sun.COM>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090819:ietf-sasl@imc.org::XcO9khQ7yKWKB+bJ:1zR4
X-Hashcash: 1:22:090819:nicolas.williams@sun.com::xQBD+AnB68GkFtvc:5LOR
X-Hashcash: 1:22:090819:tls@ietf.org::9tI8e5seg85tFhXg:Bi0/
Date: Wed, 19 Aug 2009 02:14:38 +0200
In-Reply-To: <20090818225934.GW1043@Sun.COM> (Nicolas Williams's message of "Tue, 18 Aug 2009 17:59:34 -0500")
Message-ID: <87bpmcbqxd.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
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 00:14:49 -0000

Nicolas Williams <Nicolas.Williams@sun.com> writes:

> On Wed, Aug 19, 2009 at 12:45:17AM +0200, Simon Josefsson wrote:
>> Quoting:
>> 
>>    Description: The hash of the TLS server's end entity 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 end
>>    entity certificate.)
>> 
>> I suggest replacing "server's end entity certificate" with "server's
>> certificate".  As far as I understand, it is possibly to use non-EE
>> certs, e.g. proxy certs, as a server certificate.  The RFC 5246
>> terminology is to say "sender's certificate" and there is no requirement
>> to use a EE cert.
>
> OK.  The thing to emphasize is that we're talking about the first cert
> in the certificate_list that would be sent by the server.
>
> (I say "would be" just to be mindful of the TLS client caching
> extensions, but I don't think the I-D has to say "would" since the
> certificate_list will always have been sent at one point or another.)
>
> So how about:
>
>    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 ...

Looks fine to me.

>> Quoting:
>> 
>>    agility.  The algorithm to be used, however, is derived from the
>>    certificate itself: use SHA-256 if the certificate uses MD5 or SHA-1,
>>    else use whatever hash function the certificate uses.  This
>> 
>> Please say "is signed with" instead of "uses".  Hash values may be
>> present for other purposes in a certificate, but signature fields will
>> typically only use one hash function.
>
> 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.

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

/Simon