Re: [CHANNEL-BINDING] Last Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard

[Simon Josefsson <[e-mail]>]

I support the goal of this document, i.e. to publish the text in the
IANA repository as an RFC.

There are differences between the text in the current IANA repository
and the document.  These differences are not spelled out in the document
for the 'tls-server-end-point' channel binding.  The document says:

   Note that the only material changes from the original registration
   should be: the "owner" (now the IESG), the contacts, the published
   specfication, and a note indicating that the published specification
   should be consulted for applicability advice.

That is not correct, compare the content registered with IANA

  The hash of the TLS server's end entity certificate 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.) The hash function to be
  selected is as follows: if the certificate's signature hash algorithm
  is either MD5 or SHA-1, then use SHA-256, otherwise use the
  certificate's signature hash algorithm.  The reason for using a hash
  of the certificate is that some implementations need to track the
  channel binding of a TLS session in kernel-mode memory, which is often
  at a premium.

with what the document says:

   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:

   o  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];

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

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

   The reason for using a hash of the certificate is that some
   implementations need to track the channel binding of a TLS session in
   kernel-mode memory, which is often at a premium.

I suggest that the first paragraph quoted above from section 4 is
modified like this:

OLD:
   Note that the only material changes from the original registration
   should be: the "owner" (now the IESG), the contacts, the published
   specfication, and a note indicating that the published specification
   should be consulted for applicability advice.

NEW:
   Note that the only material changes from the original registration
   should be: the "owner" (now the IESG), the contacts, the published
   specfication, and a clarification to the description related to
   certificate's that do not use hash functions or use multiple hash
   functions.  We also added a note indicating that this specification
   contains applicability advice, and we moved security considerations
   notes to the security considerations section of this document.

The last sentence is copied from section 3 for consistency.

Also missing is in section 3 and section 5 is a note that references
were added to the text.  I suggest:

OLD:
   ...security considerations section of this document.  All other
   fields of the registration are copied here for the convenience of
   readers.

NEW:
   ...security considerations section of this document.  References were
   added to the description.  All other fields of the registration are
   copied here for the convenience of readers.

/Simon