2

I have been reading RFC 5246 on TLS 1.2 and have a few questions on algorithms chosen. Before I start, let me clarify that I am reading on 1.2 and not 1.3 because my ultimate interest is in DTLS 1.2. I am confused with what appears to me to be conflicting definitions of cipherSuites, key exchange algorithm, bulk encryption algorithm, MAC algorithm and signature algorithms.

I want to deal with a simple situation of a server certificate and no client certificate. In that context, the following questions arise:

First, 7.4.1.1 states:

 Each cipher suite defines a key
 exchange algorithm, a bulk encryption algorithm (including secret key
 length), a MAC algorithm, and a PRF.  The server will select a cipher
 suite or, if no acceptable choices are presented, return a handshake
 failure alert and close the connection. 

My naive understanding is that all the algorithms required are right here in this exchange. Specifically because the Server Hello replies with a single cipher_suite meaning it has selected one (or closed). But then comes section 7.4.1.4.1 talking about "Signature Algorithms" extension. So, a signature algorithm can be specified through an extension. But a paragraph later in the same section states:

 The semantics of this extension are somewhat complicated because the
 cipher suite indicates permissible signature algorithms but not hash
 algorithms.  Sections 7.4.2 and 7.4.3 describe the appropriate rules.

So, does it mean that the Signature-algorithms extension is used to specify the Signature Algorithm from a set of signature algorithms selected by the server from a possibly bigger set offered by the client in the Client Hello?

What does 7.4.2 refer to, in relevant part? It gives permissible mappings between Key Exchange Algo and Certificate Key Type.

To make things more confusing for me comes Section 7.4.3:

  The ServerKeyExchange message is sent by the server only when the
  server Certificate message (if sent) does not contain enough data
  to allow the client to exchange a premaster secret.  

What exactly is this "enough data"? Does a standard (whatever that implies!) certificate not have "enough data" any way? Will the server not have picked the key-exchange-algo, when sending the Server Hello, to match the server Certificate it sent?

Then in that same section, comes this:

 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.  Note
 that this implies that a certificate containing a key for one
 signature algorithm MAY be signed using a different signature
 algorithm (for instance, an RSA key signed with a DSA key).

I do not understand "... a certificate containing a key for one..." The only key that a certificate has is the public key. The signature of the key as well as the algorithm used to sign it are part of the certificate. Why is a signature algorithm needed in extensions to deal with this issue?

IS THERE ANY DOCUMENT TO EXPLAIN THE ABOVE ISSUES in more detail or in simple form? Most tutorials deal with an overall summary but not with such details.

2

First, 7.4.1.1 states: Each cipher suite defines a key exchange algorithm, a bulk encryption algorithm (including secret key length), a MAC algorithm, and a PRF. ....

My naive understanding is that all the algorithms required are right here in this exchange.

No. A (pre-TLS1.3) ciphersuite defines many of the algorithms used, but not all. It defines the ones that are in the list you quoted, and it doesn't define the ones that aren't in that list. That's rather the point of explicitly stating the list of things that are defined.

But then comes section 7.4.1.4.1 talking about "Signature Algorithms" extension. So, a signature algorithm can be specified through an extension. But a paragraph later in the same section states:

The semantics of this extension are somewhat complicated because the cipher suite indicates permissible signature algorithms but not hash algorithms. Sections 7.4.2 and 7.4.3 describe the appropriate rules.

So, does it mean that the Signature-algorithms extension is used to specify the Signature Algorithm from a set of signature algorithms selected by the server from a possibly bigger set offered by the client in the Client Hello?

Kind of. There can be and often is more than one signature used, and thus possibly more than one signature algorithm used. Each signature must meet both the constraints given by the ciphersuite, where applicable, and the sigalgs extension, if present. As it says, these are detailed in 7.4.2 and 7.4.3.

What does 7.4.2 refer to, in relevant part? It gives permissible mappings between Key Exchange Algo and Certificate Key Type.

So it does, and immediately afterward 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.  Note
   that this implies that a certificate containing a key for one
   signature algorithm MAY be signed using a different signature
   algorithm (for instance, an RSA key signed with a DSA key).  This is
   a departure from TLS 1.1, which required that the algorithms be the
   same.  Note that this also implies that the DH_DSS, DH_RSA,
   ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the
   algorithm used to sign the certificate.  Fixed DH certificates MAY be
   signed with any hash/signature algorithm pair appearing in the
   extension.  The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are
   historical.

(You quoted part of this as being in 7.4.3, but it's not, it's in 7.4.2.)

Thus the keyexchange in the ciphersuite controls the type of key in the server (EE, leaf) cert, but not the signature on that cert by the CA, which depends primarily on the type of key used by the CA and not the type of key used by the server. In addition, the simplified model often presented that the server cert is issued/signed by a CA trusted by the client is just that, simplified. In practice there are nearly always two levels of CA and sometimes more; this is indicated, though not really explained, in the description of certificate_list about a page earlier in the same section:

      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  
      ... the root ... MAY be omitted ....

Sigalgs constrains the signatures on all the certs in the chain -- possibly excepting the root, because the root signature is a dummy self-signature that needn't be checked -- and the keyexchange/ciphersuite does not.

Aside: after not having a cert/key at all, this is probably the thing server admins, operators, and programmers screw up most often. You can find lots of Qs on several Stacks about 'TLS doesn't work' which turns out to be the server not correctly sending chain certs, usually because it's configured wrong. Because it is so common some clients, especially web browsers, try to work around it and often succeed, which causes people to misunderstand and even disbelieve the problem: "My server can't be wrong, because $thing works!" "Yes $thing works AND your server is still wrong". TLS1.3 (RFC8446) relaxes this slightly -- the server is still supposed to send the full chain optionally omitting root, but is not required to do so in strict sequence.

To make things more confusing for me comes Section 7.4.3:

The ServerKeyExchange message is sent by the server only when the server Certificate message (if sent) does not contain enough data to allow the client to exchange a premaster secret.

What exactly is this "enough data"? Does a standard (whatever that implies!) certificate not have "enough data" any way? Will the server not have picked the key-exchange-algo, when sending the Server Hello, to match the server Certificate it sent?

Literally the next lines answer your question.

      ... This is true [more data is needed]
      for the following key exchange methods:

         DHE_DSS
         DHE_RSA
         DH_anon

     [plus ECDHE_RSA ECDHE_ECDSA ECDH_anon in RFC4492, 
     referenced in the next paragraph]

These key exchanges are 'ephemeral' keyexchanges -- they use a newly-created keypair for each handshake, which cannot be in the certificate because the certificate was created in advance -- often far in advance (like years). Thus the ServerKeyExchange message is needed to convey (and validate) the publickey. The server will indeed choose a keyexchange and cert-plus-static-key that are compatible with each other, as well as being permitted by the client, but most clients today will list as preferred, and most servers will choose (either on their own bat or following client preference) an ephemeral keyexchange over one that isn't, because it provides the valuable feature Forward Secrecy aka Perfect Forward Secrecy (PFS).

      It is not legal to send the ServerKeyExchange message for the
      following key exchange methods:

         RSA
         DH_DSS
         DH_RSA

      [plus ECDH_RSA ECDH_ECDSA in RFC4492]

because those keyexchanges use (and need) only the publickey in the certificate. Only the first, RSA, is commonly used; the 'static' aka 'fixed' (non-ephemeral) DH and ECDH keyexchanges are mostly useless, and the former (static-DH) require a cert that can't be obtained from any known CA.

In addition to the publickey (and mostly certificate) based keyexchanges defined in RFC5246 (and 4346 and 2246) and RFC4492, there are some other keyexchanges defined in other RFCs like PSK (Pre-Shared Key), SRP (Secure Remote Password), and Kerberos which use ServerKeyExchange (and ClientKeyExchange as well) in substantially different ways. These are not used on the public network, and only rarely even on private networks. Consult those other RFCs for details; they can be found via the IANA registry.

In TLS1.0 (and SSL3) there were 'export' ciphersuites some of which used a keyexchange called RSA_EXPORT, which for legal reasons had the restriction that an RSA key over 512 bits could be used for signing but not encryption. This meant that if the server RSA cert key was 512 bits (or less) it simply sent the cert and the client used it, but if the cert key was longer it sent ServerKeyExchange containing a 'temporary' RSA key of 512 bits (or less) to be used for encrypting the premaster secret, signed by the (longer) key in the cert. This 'export' feature had other, also very detrimental, effects as well. See RFC2246 for the awful details.

The 'appropriate rules' in 7.4.3 are on page 52, and describe the signature in the ServerKeyExchange message, which covers the body of that message plus the session nonces, and uses the publickey in the server cert:

   If the client has offered the "signature_algorithms" extension, the
   signature algorithm and hash algorithm MUST be a pair listed in that
   extension.  ....

   In addition, the hash and signature algorithms MUST be compatible
   with the key in the server's end-entity certificate.  RSA keys MAY be
   used with any permitted hash algorithm, subject to restrictions in
   the certificate, if any.

   Because DSA signatures do not contain any secure indication of hash
   algorithm, there is a risk of hash substitution if multiple hashes
   may be used with any key.  Currently, DSA [DSS] may only be used with
   SHA-1.  Future revisions of DSS [DSS-3] are expected to allow the use
   of other digest algorithms with DSA, as well as guidance as to which
   digest algorithms should be used with each key size.  In addition,
   future revisions of [PKIX] may specify mechanisms for certificates to
   indicate which digest algorithms are to be used with DSA.

As predicted, FIPS186-3 in 2009 (and -4 in 2013) define DSA with larger sizes and SHA-2 hashes, and RFC5758 in 2010 allows them in PKIX (technically modifying 3279, not 3280 or 5280).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.