[TLS] WGLC - Stepping up Hash

[Stefan Santesson <stefans@xxxxxxxxxxxxx>]

The original LC comment was:

> 4) Stepping up the choice of hash?
> If the client doesn't specify any hash algorithm, the server MUST use
> SHA-1 in the server key exchange message. (7.4.3) "If no
> "signature_algorithms" extension is present , the server MUST use SHA-1
> as the hash algorithm." The client is however not obligated to declare
> any signature_algorithms (7.4.1.4.1) "Clients SHOULD send this
> extension if they support any hash algorithm other than SHA-1."
> But what if the server has knowledge that the client does support a
> better hash? For example, the selected key exchange algorithm is
> derived from a cipher suite defining a PRF based on a better hash.
> Would it be reasonable to allow the Server to make use of the better
> hash algorithm?

This was discussed at the TLS meeting and not accepted mainly for the following reasons:

1) It would be very hard to specify the specific conditions for when a server can or cannot step up the used hash algorithm.
2) We need servers to behave uniformly on this issue.

I would however challenge condition 2) and if condition 2) is not necessary, then condition 1) falls as well.
Why is it important that all servers are designed to handle this situation uniformly? I fail to see the harm if some servers successfully deploys better security while other servers in the same situation would choose to stick to the default security level.
As long as the server can determine successfully the capacity of the client and successfully communicate the choice of algorithms, then the only thing that can happen is that we would simply allow the server to choose better security.

If there is no need for all servers to provide a uniform behavior then we don't need to specify the exact conditions under which the server can gain knowledge of the client's capacity. This can range from local configuration and local policy to a local convention based on the ciphersuites supported by the client.


Stefan Santesson
Senior Program Manager
Windows Security, Standards



_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls