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

Reply via email to