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

[Eric Rescorla <ekr@xxxxxxxxxxxxxxxxxxxx>]

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.



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


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

-Ekr




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