RE: [TLS] RE: WGLC - Stepping up Hash

[Stefan Santesson <stefans@xxxxxxxxxxxxx>]

In, line

Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@xxxxxxxxxxxxxxxxxxxx]
> Sent: den 12 december 2007 15:06
> To: Stefan Santesson
> Cc: Pasi.Eronen@xxxxxxxxx; tls@xxxxxxxx
> Subject: Re: [TLS] RE: WGLC - Stepping up Hash
>
> At Wed, 12 Dec 2007 22:30:44 +0000,
> > > > 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.
>
> Yes, it might. But that's contrary to the general goal of
> explicit signalling.
>

Not as I see it. If the server chooses to use a better hash than SHA-1, it MUST inform the client of this requirement. As to knowing the capacity, the hash in the finished message is already bound to the PRF defined by the ciphersuite. So the Server can be assured of this capacity of the client without it being explicitly stated in the client hello extension. Why is this so much harder for key and certificate exchange messages.

>
>
> > > 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.
>
> I don't agree with this. What you are proposing is that a compliant
> client could offer this cipher suite but not be able to accept
> a signature with that digest. The server would then present
> a certificate with that digest and the client would fail. That's
> an interop issue. Yes, you could have some side agreement
> between the client and the server, but you've basically
> created some new protocol that happens to just look a lot
> like TLS 1.2.
>

The server should never force the client to sign or validate anything that is not supported by the selected cipher suite.
But what if the server and client agrees to CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, but the client does not provide a signature_algorithms extension?
Following the current definition in the Server Key exchange message, the server would be forced to specify SHA-1 as hash algorithm. That does not make any sense to me.

>
> > 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.
>
> I don't understand why it's a problem to simply have the client
> offer the extension in these special cases.
>

It is not. But what if it doesn't. This should clearly be the implementation goal for all clients. However, theory and practice don't always meet and we should not create rules that prevents the server from safely step up the security level in case the client fail to send this info. Or we should REQUIRE the client to provide this extension in these cases (e.g. for some cipher suites). The client is after all not required to provide this in the current spec.




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