Before a TLS connection establishes encryption, it exchanges identifying information about client and server in plaintext. This is a potential leak of meta-information about clients and servers. This specification extends TLS with a remedy to that potential problem.

Non-normative Rationale: http://rickywiki.vanrein.org/doku.php?id=tls-5-anondh

Introduction

In the setup phases of a TLS connection, various pieces of identifying information may be exchanged before the encryption layer is activated; for instance, the following could be considered too private to share:

  • Server Name Indication, a.k.a. declaration of interest;

  • Client Crypto Suites, a.k.a. vulnerability checklist;

  • Client Certificate, a.k.a. strong identity assertion;

  • Server-trusted Root Certificates, a.k.a. vulnerability checklist.

This could be summarised as "meta-data” that could be of interest to a passive observer with a rogue interest in profiling network usage patterns.

Other protocols, such as OpenSSH, choose to first exchange keys with Diffie-Hellman (DH) before proceeding wyptth the exchange of identifying information. This has a number of benefits:

  • No identifying information is available to passive observers

  • The session is protected under Perfect Forward Secrecy

The DH key exchange algorithm has one downside though: It does not protect against active man in the middle (MITM) attacks. This means that in some later phase of the protocol, a validation must be performed to ensure that both sides are using the same secret key; this is usually based on an additional authentication method with a cryptographic bond to the prior DH session.

TLS has three ways in which DH can be introduced into the protocol:

  • Dedicated DH certificates can hold a fixed DH public key; these are usually fixed and therefore less protective in the sense of Perfect Forward Secrecy;

  • In a ServerKeyExchage with an ephemeral public DH key, usually following a “normal” server certificate. The DH key is used as the session key, which is hashed with the entire handshake procedure into a master secret that is mutually verified during the Finish exchange;

  • Among the CipherSuites available to TLS are a few that perform Anonymous Diffie-Hellman (AnonDH). To establish an authenticed session, the client can initiate a renegotiation under this protection layer.

From a privacy perspective, the third option is the most attractive, because it conceals the “meta-data" exchanged during the start of the first and second options. The use of AnonDH however, is actively advised against because it does not protect against MITM attacks.

When the client initiates renegotiation before any application data is exchanged, the MITM attack can be avoided; this specification introduces a TLS Extension to express that intention. This revives AnonDH as a usable CipherSuite because it provides clarity of intentions:

  • the server can support AnonDH as just a stepping stone towards an authenticated session;

  • the client knows that its identifying information receives better protection;

  • rogue intermediates know that MITM attacks will be detectable.

To make these properties come true, the renegotiation should be a secure renegotiation, meaning that the AnonDH session information is cryptographically bound into the authentication process. Without this binding between the two negotiation phases there would still be a risk of undetected MITM attacks to the AnonDH-cloacked exchange of “meta-data”.

TODO: Rationale: Network Effect of fear.

TLS Extension to ClientHello

The ClientHello message [RFC 5246] can hold Extension structures [RFC 6066], each identified with a unique tag. This specification introduces an Extension named pfs_anon_setup to be sent in the ClientHello message. The extension carries data of length 0.

  • A client that sends pfs_anon_setup MUST NOT transmit application_data while the TLS connection is only protected by AnonDH.

  • A server that receives pfs_anon_setup and that supports this specification MUST send the fatal error unexpected_message when it receives application_data records while the TLS connection is only protected by AnonDH.

  • A client that sends pfs_anon_setup SHOULD also offer the extension for secure renegotiation [RFC 5746].

  • A client that sends pfs_anon_setup SHOULD include one or more AnonDH CipherSuites in its ClientHello. (These CipherSuites have names starting with TLS_DH_anon_ in IANA's “TLS Cipher Suite Registry” described in RFC 5246.)

Where the above mentions application_data, this also refers to its compressed and/or encrypted forms.

TLS Extension to ServerHello

The ServerHello message [RFC 5246] can hold Extension structures [RFC 6066], each identified with a unique tag. The pfs_anon_setup extension specified in this document can be returned in the ServerHello message. This returned extension carries data of length 0.

  • A server MUST NOT send pfs_anon_setup in its ServerHello unless it receives pfs_anon_setup in an immediately preceding ClientHello.\ TODO: I am assuming this is a requirement to avoid confusing clients. It would be very useful to send the extension even if the client didn’t understand it though; it would communicate that the server is willing (would have been willing) to support the extension, and that prior evidence to the contrary might be frowned upon as a potential hijacking attempt by a rogue intermediate party.

  • A server that sends pfs_anon_setup MUST NOT transmit application_data while the TLS connection is only protected by AnonDH.

  • A client that receives pfs_anon_setup in response to the same extension in its own ClientHello MUST send the fatal error unexpected_message when it receives application_data records while the TLS connection is only protected by AnonDH.

  • A server that sends pfs_anon_setup SHOULD also offer the extension for secure renegotiation [RFC 5746].

  • Servers sending pfs_anon_setup SHOULD give higher preference to the AnonDH CipherSuites, even if these would otherwise not be considered acceptable.

  • A client that sent pfs_anon_setup in its ClientHello but does not find it back in the returned ServerHello must be cautious about any offered AnonDH CiperSuite. If the client is known to be the first to send application_data then the client SHOULD accept the situation and proceed as if the ServerHello had contained pfs_anon_setup. Otherwise, any server-sent application_data preceding renegotation may be susceptible to MITM attacks, and the client MAY want to avoid this from happening by sending a fatal handshake_error in response to the ServerHello or by responding with an error when application_data arrives under only AnonDH protection.

Where the above mentions application_data, this also refers to its compressed and/or encrypted forms.

Efficiency Considerations

This section compares two approaches to security with DH key exhange, namely DHE_RSA and the hereby presented alternative AnonDH+RSA.

  • RSA private key operations;

  • DH exponentiation operations;

The expensive operations involved in the classical solution of DHE_RSA are:

  • One DH operation on the server;

  • One DH operation on the client;

  • One RSA private key operation on the server.

The expensive operations involved in AnonDH+RSA are:

  • One DH operation on the server;

  • One DH operation on the client;

  • One RSA private key operation on the server.

When a ClientCertificate is used, there is an additional need for an RSA private key operation on the client; this is the same in both scenario’s.

To conclude, the two scenario’s are similar in their use of resources. The main difference is that the work expands into more protocol interactions.

As for a comparison for TLS with or without added DH, it is worth noting that at least server-side DH operations can be prepared before the connection starts, so responsiveness of the server can be similar.

TODO: Caching the DH calculation to support reneg with the same DH secret; possibly redefining implicit DH keys; must be kex->secret and may be cached in the same environment as the DH secret.

Security Considerations

AnonDH as a first step protects exchanged identifying information against passive observers, but it is not a protection against active MITM interceptions.

When the renegotiation takes place under the cloak of AnonDH, there is still a chance that a MITM attack is in progress; even the verifying Finished messages of the AnonDH could be forged by an active interceptor. As a result, identifying information about the session being setup is still susceptible to a MITM attack, in spite of operating under an AnonDH cloak.

The extension presented here does avoid the exchange of application_data during that phase.

Furthermore, the urged use of secure renegotiation causes failure if a MITM attack was mounted against the AnonDH part of the session. There is no way for a MITM to weasle out at this point, except by breaking off the connection. Both this and continued intrusion on the TLS connection will be detected when comparing the second-phase Finished messages. It is this facility that should help to actively discourage active participation with TLS sessions under AnonDH.

It should be noted that AnonDH can be useful even in the absense of the pfs_anon_setup extension, albeit under conditions. A client controls renegotiation, so it can always request AnonDH CipherSuites for application protocols that never send sensitive data before the client’s first application_data is sent. Similarly, a server that does not require client authentication during TLS setup is not taking any risk by accepting AnonDH requests. Specifically, there appears to be nothing to stop clients or servers from using AnonDH with immediate renegotiation for the popular HTTP protocol. Other protocols, like SMTP, remain subjected to administrator’s preference due to the initial server banner. The pfs_anon_setup extension has been defined to overcome subjectivity in those and all other situations.

IANA Considerations

This specification defines a new TLS extension value TODO, with extension name pfs_anon_setup, to be registered in the “ExtensionType Values” registry defined in RFC 5246.