Subject: [TLS] Question regarding RFC 7366

From: <[email-masked]>
Date: Tue, 2 Nov 2021 13:18:22 +0100

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 Nov 2021 13:52:24 -0400

> negotiation when using AEAD ciphers.

I think the source of the confusion is that AEAD ciphers are *neither*
encrypt then MAC, nor MAC then encrypt (as two separate operations).
They perform both as a single one-pass operation.  The extension in
question simply has no meaning with AEAD, and must not be sent by the
server when an AEAD cipher selected, in which case the client and server
just do AEAD.

-- 
    Viktor.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 4 Nov 2021 06:36:33 +0000

>intended interpretation is, i.e., when the extension should be used.

There's not really any contradiction, encrypt-then-MAC has nothing to do with
AEAD which is an all-in-one mode, so it doesn't apply to any AEAD cipher.

Peter.

---

From: John Mattsson <[email-masked]>
Date: Thu, 4 Nov 2021 11:59:36 +0000

I think the best way to think about AEAD from a protocol standpoint is as an interface. This is especially true for TLS where there are algorithms like TLS_SHA256_SHA256 for the AEAD interface that do not do encryption. A TLS cipher suite either use the AEAD interface or it does not.

Cheers,
John

From: TLS <[email-masked]> on behalf of Peter Gutmann <[email-masked]>
Date: Thursday, 4 November 2021 at 07:37
To: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [TLS] Question regarding RFC 7366

Peter.

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls