Subject: [TLS] signature_algorithms extension definition

From: Peter Bowen <[email-masked]>
Date: Wed, 10 Sep 2014 09:21:48 -0700

The TLS 1.2 RFC is a little ambiguous on the meaning of the contents
of the signature_algorithms extension when included in a ClientHello
message.  It says "pairs [which] may be used in digital signatures"
and "pair[s] that the client is willing to verify".  Later on it says
"If the client provided a 'signature_algorithms' extension, then all
certificates provided by the server MUST be signed by a hash/signature
algorithm pair that appears in that extension."

What is unclear is whether the client MUST be willing and able to
verify _certificates_ signed with any of the pairs that it specifies.
There are popular clients that support one set of pairs for signing
TLS messages (digitally-signed structs) but that support a different
set for signing certificates.  For example, they support sha256/rsa
and sha1/rsa for TLS signing but only sha1/rsa for certificate
signing.

Is the intent that a peer which sends the signature_algorithms
extension must be willing to validate certificates signatures using
any of the pairs in the extension?  If not, should TLS 1.3 add a flag
to indicate which pairs are valid for which types of signatures?

Thanks,
Peter

---

From: Brian Smith <[email-masked]>
Date: Wed, 10 Sep 2014 09:32:05 -0700

> verify _certificates_ signed with any of the pairs that it specifies.

Effectively, yes, it should, because the server is allowed to choose
certificates that use any of the signature algorithms listed. If the
algorithm list in signature_algorithms is misleading, then the client
risks interoperability issues. In practice, a client should list only
algorithms that it supports for BOTH the ServerKeyExchange message AND
certificates.

> to indicate which pairs are valid for which types of signatures?

This is already a known issue. My idea is to have a
certificate_signature_algorithms extension, with the same syntax as
signature_algorithms. When certificate_signature_algorithms is present
in the ClientHello, the algorithms in signature_algorithms are only
for the ServerKeyExchange signature, and the algorithms in
certificate_signature_algorithms are used for certificates. When
certificate_signature_algorithms is missing, then the server uses
signature_algorithms for both. This way, only the clients actually
affected by this issue need to do any new work.

Cheers,
Brian

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 Sep 2014 09:42:29 -0700

> and sha1/rsa for TLS signing but only sha1/rsa for certificate

Yes.

> to indicate which pairs are valid for which types of signatures?

I'd be interested in hearing if this is a problem for a significant number
of
clients.

-Ekr

---

From: Peter Bowen <[email-masked]>
Date: Wed, 10 Sep 2014 09:57:56 -0700

On Wed, Sep 10, 2014 at 9:42 AM, Eric Rescorla <[email-masked]> wrote:
> of clients.

Google Chrome/Chromium is one notable client.  It uses an internal TLS
implementation but uses the OS crypto stack for certificate
validation, resulting in situations where different algorithm pairs
are supported in different contexts.

Thanks,
Peter

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 Sep 2014 10:01:05 -0700

> are supported in different contexts.

Hmm... It seems like Chrome could just offer the intersection of the
algorithms,
as NSS/OpenSSL will generally have a superset of the OS algorithms.

-Ekr

---

From: Adam Langley <[email-masked]>
Date: Wed, 10 Sep 2014 10:10:46 -0700

> as NSS/OpenSSL will generally have a superset of the OS algorithms.

We will. I just didn't realise that the signature_algorithms extension
was supposed to apply to more than just the TLS handshake.

It's https://code.google.com/p/chromium/issues/detail?id=409901. It
*should* be done for Chrome 39.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Peter Bowen <[email-masked]>
Date: Wed, 10 Sep 2014 22:14:48 -0700

> was supposed to apply to more than just the TLS handshake.

Should this get called out in 1.3 to make it clearer?  Should there be
an erratum for 1.2?

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 11 Sep 2014 11:15:57 +0200

> algorithm pair that appears in that extension."

The second sentence is ignored by implementations, as there is no way to
enforce it. The server has no way to switch the signatures in his
certificates. The certificates are provided by a third party (the CA),
which is not participating in the handshake in order to modify the
certificates. It would be a good thing if the latter sentence was
dropped in the new TLS 1.3 specification, or at least switched to MAY. 

regards,
Nikos

---

From: Peter Bowen <[email-masked]>
Date: Thu, 11 Sep 2014 07:26:52 -0700

> dropped in the new TLS 1.3 specification, or at least switched to MAY.

Why do you say it is ignored?  This whole extension is critical to
implementing certificate agility (multiple certificates for the same
name).  Agreed the CA is not in the handshake, but the server is and
may already have multiple certificates from the CA.

Thanks,
Peter

---

From: [email-masked] (Martin Rex)
Date: Thu, 11 Sep 2014 16:47:04 +0200 (CEST)

> dropped in the new TLS 1.3 specification, or at least switched to MAY. 

+1

Similar to the TLS server_name_indication extension, the signature
algorithms listed in the signature algorithms extension should be
merely a hint for the server to select the _best_fit_ server certificate
(chains) from those server certificates that it has available (which
may be few, or just one).

If the TLS client has specific (policy) requirements on acceptable
algorithms, the client will have to perform his own checks in any
case, and it would be entirely unreasonable for the server to
preempt the clients decision whether to continue (best effort style),
with or without confirmation from an interactive user at the client.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 12 Sep 2014 06:45:37 -0700

> with or without confirmation from an interactive user at the client.

It's important to distinguish between requirements on the server and
requirements on the client:

- The point of the extension is to guide certificate selection on the server
  (or the client in the case of client Certificates) so it's appropriate to
have
  a normative requirement encouraging the server to conform. In the current
  text this is a MUST but if there's some good reason to relax it to a
SHOULD
  we could certainly do so. It's not clear to me what that reason is,
though.
  Modulo bugs is there some reason why a client would advertise support
  for signature algorithms X and Y when it actually supports X, Y, and Z?

- I agree that it's probably not necessary for the client to enforce the
  server's conformance with the extension. However -- and maybe I'm
  missing something here -- I don't see where in the text it is required
  to do so. A requirement that the server MUST do something is not a
  requirement that the client check it. For instance, it's quite common
  to have reserved fields which must be set to a given value but
  ignored on the other side, as in [0].

-Ekr

[0] http://tools.ietf.org/html/rfc4733#section-2.3.3

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 12 Sep 2014 17:00:34 +0200

On Fri, 2014-09-12 at 06:45 -0700, Eric Rescorla wrote:
>   (or the client in the case of client Certificates) so it's
> appropriate to have

A scenario where the MUST would have have prevented interoperation:
"A client which supports SHA256 and SHA1 is configured to ask RSA-SHA1
as signature algorithm. It connects to the server. The server's
certificate is signed with SHA256. According to the text above the
server shouldn't send his certificate to the client, as he cannot comply
with the MUST. So the server terminates the handshake to comply with the
spec, even though the client could have been able to verify the
certificate."

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 12 Sep 2014 08:30:28 -0700

> spec, even though the client could have been able to verify the

Can you help me understand how we get into that scenario? I.e., why did the
client send RSA-SHA1 if it supported SHA256?

I'm trying to figure out what the general governing principle is here. For
instance, RFC 4492 requires that the server respect the client's supported
curve extension http://tools.ietf.org/html/rfc4492#section-5.3:

" The server constructs an appropriate certificate chain and conveys it

   to the client in the Certificate message.  If the client has used a
   Supported Elliptic Curves Extension, the public key in the server's
   certificate MUST respect the client's choice of elliptic curves; in
   particular, the public key MUST employ a named curve (not the same
   curve as an explicit curve) unless the client has indicated support
   for explicit curves of the appropriate type.  If the client has used
   a Supported Point Formats Extension, both the server's public key
   point and (in the case of an explicit curve) the curve's base point
   MUST respect the client's choice of point formats.  (A server that
   cannot satisfy these requirements MUST NOT choose an ECC cipher suite
   in its ServerHello message.)"

Do you believe that these MUSTs and MUST NOTs are inappropriate?

If not, can you explain what the difference is here?

Thanks,

-Ekr