Re: [TLS] First TLS cached information draft posted

[Simon Josefsson <[e-mail]>]

Stefan Santesson <[e-mail]> writes:

> Simon,
>
> The specification allows you to specify and use any hash algorithm that is
> supported by the TLS hash algorithm registry.
>
> SHA-1 is the only MUST support algorithm, and I think that is correct.

That's fine.

In practice, I guess client implementations are likely to send:

CachedInformation =
  {
    { certificate_chain { sha1, "..." } },
    { certificate_chain { sha2-512, "..." } },
    ...
  }

How should a server behave if it receives a HashAlgorithm it doesn't
support, for a CachedInformationType it does support?

I suggest unsupported hashes should be ignored by servers.  I think some
guidance in the document is needed to make sure algorithm agility will
work.

In other words, after:

   Hash algorithm identifiers are provided by the RFC 5246 [RFC5246]
   HashAlgorithm registry. Compliant implementations MUST support
   sha1(2) as HashAlgorithm.

add this sentence:

   Servers MUST ignore unsupported hash algorithm identifiers.

This leads to the possibly surprising behaviour that if a sha1 value is
not sent by the client, and the server only supports sha1, the extension
will not be negotiated.  But that is right, isn't it?

/Simon

> /Stefan
>
>
> On 09-06-05 2:36 PM, "Simon Josefsson" <[e-mail]> wrote:
>
>> A minor discussion would be whether adding support for SHA-256/384/512
>> is worthwhile, but I don't feel strongly either way.