6. Security Considerations

6. Security Considerations

The transmission of raw public keys, as described in this document, provides benefits by lowering the over-the-air transmission overhead since raw public keys are naturally smaller than an entire certificate. There are also advantages from a code-size point of view for parsing and processing these keys. The cryptographic procedures for associating the public key with the possession of a private key also follows standard procedures.

However, the main security challenge is how to associate the public key with a specific entity. Without a secure binding between identifier and key, the protocol will be vulnerable to man-in-the-middle attacks. This document assumes that such binding can be made out-of-band, and we list a few examples in Section 1. DANE [RFC6698] offers one such approach. In order to address these vulnerabilities, specifications that make use of the extension need to specify how the identifier and public key are bound. In addition to ensuring the binding is done out-of-band, an implementation also needs to check the status of that binding.

If public keys are obtained using DANE, these public keys are authenticated via DNSSEC. Using pre-configured keys is another out-of-band method for authenticating raw public keys. While pre-configured keys are not suitable for a generic Web-based e-commerce environment, such keys are a reasonable approach for many smart object deployments where there is a close relationship between the software running on the device and the server-side communication endpoint. Regardless of the chosen mechanism for out-of-band public key validation, an assessment of the most suitable approach has to be made prior to the start of a deployment to ensure the security of the system.

An attacker might try to influence the handshake exchange to make the parties select different certificate types than they would normally choose.

For this attack, an attacker must actively change one or more handshake messages. If this occurs, the client and server will compute different values for the handshake message hashes. As a result, the parties will not accept each others' Finished messages. Without the master_secret, the attacker cannot repair the Finished messages, so the attack will be discovered.