Re: [TLS] TLS 1.2 hash agility

[Eric Rescorla <ekr at networkresonance.com>]

At Thu, 27 Sep 2007 08:00:49 -0700,
Mike wrote:
> >> The only counter argument I could find is that the server's list
> >> of acceptable algorithms might be different in different places.
> > 
> > And yet, I mentioned several other reasons in my previous message:
> > 
> > - Locality of information.
> 
> For CertificateRequest, yes, but by putting it there, the client
> has to parse the Certificate to figure out if it is signed with
> an acceptable algorithm.  If the server's list of acceptable
> algorithms was passed in a ServerHello extension, the client
> would be able to determine if it should even bother.  (That is
> the benefit I referred to above.)

I'm sorry, I don't understand your point: the client tells
the server what algorithms it supports. A compliant server
MUST NOT send a certificate with a different algorithm,
but rather abort the connection. The client at this point
needs to assume that the server's certificate is OK and
parse it, yes. But if we're assuming that the server is
noncompliant, then you can't count on the indicator you're
talking about anyway.

You and I seem to be assuming different semantics here:
the design I propose is not a negotiation. The client says
"I will accept stuff signed with X" and the server does
likewise. The only restriction is that the signer use an
algorithm within the other side's set. These sets need
not intersect.


> > - It works even if the client does not offer the extension.
> 
> A client that does not offer the extension doesn't support any
> advanced algorithms.  If it did, why wouldn't it tell the server?

It might have a certificate signed with a better algorithm but that
it can't itself verify. It might simply be configured to prefer
a certain set of algorithms. Remember that the signature over
the client's certificate and CertificateVerify is for the 
client's benefit, not the servers, and vice versa, so just 
because you only trust algorithm X doesn't mean you can't
generate algorithm Y.

> >> Even if so, the client can benefit from knowing the server's
> >> certificate signature algorithms up front, so having the server
> >> respond with the extension is useful.
> > 
> > I don't see any significant value in this.
> 
> In the end, it is your specification, so all I can do is present
> my point of view....

This is a WG document, so it's actually the WG's position that
matters. But given that you and I are the people who have
expressed opinions...

-Ekr


_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls