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

From: Simon Josefsson <[email-masked]>
Date: Wed, 19 Aug 2009 00:45:17 +0200

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.

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.

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.

Nits:

   note (that is, the first such note in the descritption is a new
                                                   ^
/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Aug 2009 16:34:28 -0500

Per RFC5056, three channel binding types for TLS have been registered in
the IANA channel binding type registry.  Recently we've decided that we
actually need a Standards-Track RFC to define these channel binding
types so as to make it easier to make normative reference to them.

Therefore we've revived and updated draft-altman-tls-channel-bindings to
include the text of those three channel binding type registrations, as
well as to update introductory and security considerations text.

We seek comments on draft-altman-tls-channel-bindings-05.  In two weeks
we'll request that an AD shepherd this individual submission.  We seek
Proposed Standard status for the resulting RFC.

Consider this a pseudo-WGLC.  Please review and comment.

Thanks,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Aug 2009 17:59:34 -0500

> terminology is to say "sender's certificate" and there is no requirement

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

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

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?

>    specification needs to be updated to resolve which hash function

Good point.

Thanks!

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 19 Aug 2009 02:14:38 +0200

>    element of which is the server's certificate.)  The hash function ...

Looks fine to me.

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

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 Aug 2009 11:17:28 -0500

On Wed, Aug 19, 2009 at 02:14:38AM +0200, Simon Josefsson wrote:
> >    Description: ...

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.

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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 Aug 2009 16:22:24 -0500

>    specification needs to be updated to resolve which hash function

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.

Traditionally a digital signature

	S'(Kp, M) = S(Kp, H(M))

while in NIST-SP-800-106

	S'(Kp, M) = {rv = rng(rv_len),
		     S(Kp, H(rv ||
			     (pad(M, rv_len) XOR xor_pad_gen(rv) ||
			     rv_length_indicator(rv_len))))
		    }

One could imagine this, however:

	S'(Kp, M) = {mk = rng(),
		     S(Kp, MAC(k, M))}

in which case there'd be no hash function.  Of course, we could define a
pseudo-hash function in that case: H(x) = MAC(mk, x), where mk is the mk
that would appear in the signature.

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.

Comments?

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Aug 2009 00:25:38 +0200

Nicolas Williams <[email-masked]> writes:

> of digital signatures.

I agree, we could decide to not resolve this concern.

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

If use of SHA-512 is hard-coded, we run into problem when it is phased
out.  Negotiation any other hash function will be tricky.  Alas, I'm not
sure leaving it undefined is any better: negotiating what hash function
to use in that situation seems equally tricky.

This is one reason where deriving channel binding data from the TLS
channel using tls-extractor appears more robust: it leaves negotiation
of the hash function to the TLS protocol.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 Aug 2009 17:22:29 -0500

On Wed, Aug 19, 2009 at 04:22:24PM -0500, Nicolas Williams wrote:
> ...

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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 Aug 2009 17:26:58 -0500

> to use in that situation seems equally tricky.

I chatted with Jeff Hutzelman about this, and we both concluded that
leaving tls-server-end-point undefined in this case is acceptable
because we could change the spec to define tls-server-end-point for such
signature algorithms when they arise.

> of the hash function to the TLS protocol.

tls-unique does that already (though not using the extractor).  We're
talking about end-point channel binding types here, which are
independent of actual channels, therefore we couldn't use the extractor.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 20 Aug 2009 10:07:20 -0400

>       type may occur to address this issue if it ever arises).

+1

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 24 Aug 2009 10:20:59 -0600

> types so as to make it easier to make normative reference to them.

Thanks, this is helpful.

> Proposed Standard status for the resulting RFC.

The TLS list seems more appropriate than [email-masked] as the location
for expert review.

Nit: cryptographycally => cryptographically

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 24 Aug 2009 12:49:16 -0500

> The TLS list seems more appropriate than [email-masked] as the location
                   ^ of changes to these channel binding types.

Good point.  I'll make the change.  (But perhaps the TLS WG doesn't
agree?  If so, pipe up!)

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 31 Aug 2009 14:56:52 -0500

I've just posted version -06, incorporating all changes agreed so far.

This pseudo-WGLC started on August 18th.  Tomorrow I'll ask Pasi to take
the next step in the publication process.

Thanks,

Nico
--