Re: [TLS] Server Signature Algorithms

[Martin Rex <Martin.Rex at sap.com>]

Michael Gray wrote:
> 
> 
> "Michael D'Errico" <mike-list at pobox.com> wrote:
> 
> > There are now at least 3 instances where a TLS client needs to know the
> > server's list of supported signature algorithms:
> >
> >     1. to compute the signature for the CertificateVerify message
> >     2. to compute the hash of the handshake messages in (1) without
> >        having to hold onto all of the messages
> >     3. to compute hashes for the proposed cached information extension
> >
> > Rather than duplicate the list for each of these and any future needs,
> > it makes sense to send it once in a server hello extension.
> >
> > The simplest option would be to use the existing signature algorithms
> > extension and make it symmetrical.  But if there is a deployed client
> > out there that aborts a connection if it receives a signature algorithm
> > extension, then a secondary option would be to create a new server-
> > signature-algorithms extension which is identical in structure to the
> > existing extension.
> >
> > I would add that when the server sends its list of algorithms in the
> > extension, then it MUST NOT send a different list in the certificate
> > request message; in fact it SHOULD send an empty list.  TLS 1.3 can
> > decide whether to eliminate the list from CertificateRequest.
> 
> Currently our toolkit when operating as a client will abort the handshake
> on this condition due to RFC 5246 in 7.4.1.4.1 saying: â??Servers
> MUST NOT send this extensionâ??.

That isn't strict, that is anal.

It would safe to entirely ignore an extension that should not be present,
and this is what the general rule _implies_:

   "Be liberal in what you accept, be conservative in what you send out."


-Martin