[TLS] RE: WGLC - Stepping up Hash

[<Pasi.Eronen@xxxxxxxxx>]

Stefan Santesson wrote:

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

Completely uniform server behavior is perhaps not needed, 
but interoperability is.

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

Do you mean something along the lines "if the client
proposes ciphersuite TLS_X_WITH_Y, then the server assumes
that the client will also support hash Z, even though
the client didn't include Z in signature_algorithms
extension"?

This sounds like a recipe for horrible interop problems
unless the specification actually says that "all implementations
which support TLS_X_WITH_Y must also support hash Z". While
this could perhaps be done, I don't quite understand why
it would be useful: if the client does indeed support Z, it 
will include it in the signature_algorithms list. If it
doesn't include it, it either doesn't support it, or does
not want to use it (in this context).

Best regards,
Pasi


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