Dear ladies and gentlemen,
my question addresses the negotiation of the "encrypt_then_mac" extension proposed in RFC 7366 and, specifically, two possible interpretations of such negotiation when using AEAD ciphers. In summary, the client and server could interpret the negotiation of the extension differently during the handshake. Detailed description: In section 2 of RFC 7366, it states that "the client and server MUST NOT use encrypt-then-MAC unless both sides have successfully exchanged encrypt_then_mac extensions." This unambiguously implies that the encrypt_then_mac extension must not be used, if either the client or the server did not include the extension in their Hello messages during handshake. In this section, no restrictions is made whether encrypt_then_mac is to be used with only certain ciphersuites. However, in section 3, it is stated that "If a server receives an encrypt-then-MAC request extension from a client and then selects a stream or Authenticated Encryption with Associated Data (AEAD) ciphersuite, it MUST NOT send an encrypt-then-MAC response extension back to the client." Consequently, the correct/RFC-compliant behavior is unclear when the client and server wish to use mac_then_encrypt and an AEAD cipher such as AES_GCM. Two scenarios can exist as follows. 1. The client includes the encrypt_then_mac extension and AES_GCM as the ciphersuite in its Client Hello. The server responds and includes the encrypt_then_mac extension and AES_GCM in its Server Hello. Both sides have negotiated encrypt-then-MAC and apply it accordingly. This complies with section 2 but contradicts section 3 of the RFC. 2. The client includes the encrypt_then_mac extension and AES_GCM as the ciphersuite in its Client Hello. The server responds and does not include the encrypt_then_mac extension in its Server Hello. The chiphersuite remains to be AES_GCM. Following section 3, the server did not include the extension. However, based on section 2, this voids the usage of encrypt-then-MAC. For instance, the client may follow section 3 and apply encrypt_then_MAC, while the server does not as it follows section 2 of the RFC. I would really appreciate a response to get some clarification on what the intended interpretation is, i.e., when the extension should be used. Thank you and with best regards, Alexander Schlie
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls