[TLS] RE: WGLC - Stepping up Hash

[Stefan Santesson <stefans@xxxxxxxxxxxxx>]

In line;

Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: Pasi.Eronen@xxxxxxxxx [mailto:Pasi.Eronen@xxxxxxxxx]
> Sent: den 12 december 2007 03:28
> To: Stefan Santesson; tls@xxxxxxxx
> Subject: RE: WGLC - Stepping up Hash
>
> 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.
>

Great. A interoperability problem that would not be acceptable is if a Server based on how TLS 1.2 is defined, falsely assumes that a client can do hash Z.


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

Yes and No. No I don't want this assumption to be defined in the protocol. That would be pretty ugly and would have to be defined per cipher suite.
But Yes, the server may have deterministic knowledge that in the pool of clients it serves (or for the particular service it provides) either all clients, or a subgroup of the clients that uses a particular cipher suite, in fact can handle Hash Z.

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

This is not a matter of when a Server should select hash Z. This is a matter of allowing the server to select hash Z when the server knows that the client can, or must be able to, use hash Z. In this case there can't be any interop issues by definition. As TLS 1.2 currently is written, the Server is prohibited from stepping up the security even if it knows that it would not cause any problems.




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