With Encrypt-then-MAC, and flexible protocols, do I need to authenticate the authentication?

Question

Sorry, the question is not easy to state (or wasn't for me, anyhow).

So I'm writing a very flexible format for security. It allows for full choice of cipher, key size, and so on, along with key confirmation and derivation. All of this is communicated in objects with Protocol Buffers serialisation. Now, I get that I need to authenticate the cipher configuration (using Encrypt-then-MAC), but in my protocol, the authentication method itself is highly configurable just like the rest. Is this a situation where I need to NOT provide flexibility, or can I actually NOT "authenticate the authentication"? I would prefer retaining the flexibility, but not at the cost of security.

The high level description of a PayloadItem (the format that defines how to write/read an item to/from the payload) is, with their types:

• Type (string)
• Name (string)
• ExternalLength (long)
• InternalLength (long)
• Encryption (SymmetricCipherConfiguration)
• KeyConfirmation (VerificationFunctionConfiguration)
• KeyDerivation (VerificationFunctionConfiguration)

And I am thinking of adding EncryptionAuthentication (as a VerificationFunctionConfiguration) ... it seems to me that I cannot authenticate KeyConfirmation or KeyDerivation (I do not have the key at this point, yet, after all), too. Please help me through the security implications of this. I have already thought about the problem a good deal but would like some thoughts from others.

The key confirmation works by accepting a set of possible keys a receiver holds for a sender, and iterating through them, testing for equality with a verified output. The confirmation method is configured by its configuration object, which allows use of a MAC or KDF, with salt.

Similarly the key derivation is configured by its configuration object, allowing a selection of functions.

Is it okay if I just make sure that I do NOT use short-circuiting comparisons?

Answer 1

Though a full analysis would require some details and, presumably, a lot of work, guidance can be obtained from what is done in SSL: at the end of the handshake, a verification step occurs with the Finished messages. These messages are protected with the negotiated algorithms and keys (both encryption and MAC) and, crucially, the contents of a Finished message are a one-way hash of all the previously exchanged handshake messages, thus including the cipher negotiation, the server's public key, the key exchange messages... For instance, see this article for some discussion on the subject. The security of the SSL handshake against various types of active attacks relies heavily on the contents of these Finished messages, and (this must not be forgotten) on their mandatory aspect (client and server ought to refuse to send or receive application data until they have sent/received appropriate Finished messages).

With such a verification, a client (or server) implementing SSL will ensure some security level against active attacks on the handshake which should be at least as great as the weakest of the MAC algorithms that the client (or server) accepts to use. Getting beyond that level (i.e. showing a posteriori that a given connection was protected with the strength of the MAC algorithm which was apparently used, regardless of whether some system would have accepted a weaker MAC) can get tricky.