Subject: [TLS] Server signature in signed-Diffie-Hellman

From: Douglas Stebila <[email-masked]>
Date: Thu, 15 May 2014 00:32:30 +0000

The TLS 1.3 wish list makes mention of modifying what is signed by the server in signed-Diffie-Hellman ciphersuites to avoid the cross-ciphersuite attack of Mavrogiannopoulos et al. (CCS 2013).  Presumably this change would be for the server to sign the entire transcript up until that point, just like the client does in its CertificateVerify message, which is a very good idea.

If changes to the server signature are in the cards, I'd propose that we further separate the signature from the ServerKeyExchange, and move the server's signature to a separate CertificateVerify message immediately before the [ChangeCipherSpec], just like on the client side.

While there are no attacks involved in the server signature being in its current location, it is not very "clean" from a cryptographic perspective, as can be seen in the hoops that Jager et al. (CRYPTO 2012) and Krawczyk et al. (CRYPTO 2013) had to go through in order to prove signed-DH secure.  Right now, server-to-client authentication can be broken by an adversary who can break the signature scheme (at the point of the ServerKeyExchange message) OR who can break the DH key exchange (at the point of the Finished message).  As a result, the server-to-client authentication proofs in the aforementioned papers have to make use of a Diffie-Hellman assumption, and in particular had to invent a non-standard DH assumption called PRF-ODH because the Finished message is encrypted under the session key.  Moving the server's signature to a separate CertificateVerify message just before the [ChangeCipherSpec] should alleviate the need for server-to-client authentication to also depend on PRF-ODH, instead leaving it to depend solely on the security of the signature scheme.  SSH uses this structure for signed-DH, and we were able to make a proof of server-to-client authentication go through just assuming the security of the signature scheme (http://eprint.iacr.org/2013/813).  

There's no particular reason to doubt the security of PRF-ODH as Watson explained on the CFRG mailing list.  But things might change if/when we move to post-quantum key exchange primitives.  For example, oracle-ring-learning-with-errors is insecure even if ring-learning-with-errors is secure (http://eprint.iacr.org/2014/070, section 5.3).

This doesn't take into account engineering / performance challenges or benefits, which I hope others on the list can illuminate.

Off the top of my head, this could slightly reduce load on the server due to malicious clients.  At present, a malicious client can make the server do a group operation (generate ServerKeyExchange ephemeral public key), signature (sign ServerKeyExchange), and another group operation (generate pre-master secret) before the server realizes the client's handshake is invalid (failed Finished message).  Moving the server signature later would mean the server doesn't have to sign until after it has verified the client's Finished message, saving one public key operation.  I guess the flip side is that client's can't reject as early, but that seems like less of a concern.

Were there particular reasons why the server signature was put where it is when SSL/TLS was original designed?

Douglas

---

From: [email-masked] (Martin Rex)
Date: Thu, 15 May 2014 03:24:17 +0200 (CEST)

Douglas Stebila wrote:
>
> The TLS 1.3 wish list makes mention of modifying what is signed
> by the server in signed-Diffie-Hellman ciphersuites to avoid the
> cross-ciphersuite attack of Mavrogiannopoulos et al. (CCS 2013).
> Presumably this change would be for the server to sign the entire
> transcript up until that point, just like the client does in its
> CertificateVerify message, which is a very good idea.
> 
> If changes to the server signature are in the cards, I'd propose
> that we further separate the signature from the ServerKeyExchange,
> and move the server's signature to a separate CertificateVerify
> message immediately before the [ChangeCipherSpec], just like on
> the client side.

Having the server use a CertificateVerify message closer to what
the client uses seems OK, but moving it past ServerHelloDone
does not seem like a good idea.

Recall the full handshake messages:

https://tools.ietf.org/html/rfc5246

      Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

             Figure 1.  Message flow for a full handshake

With a (Server)CertificateVerify just prior to ServerHelloDone, the
client would be able to verify the server certificate before sending
his own certificate, so the client would be able to limit which
servers (attackers) it is willing to disclose a client certificate to.

In the existing TLS protocol versions, an active attacker can always
make a client disclose his client certificate by doing an MITM on the
beginning of the TLS handshake.

Admittedly, a real benefit will only materialize if TLSv1.3 provides
confidentiality protection for the Client's Certificate handshake
message.

-Martin