Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?

From: Peter Gutmann <[email-masked]>
Date: Thu, 30 Oct 2014 09:40:24 +0000

Nikos Mavrogiannopoulos <[email-masked]> writes:

>So is my understanding correct that no deployed implementation is compliant
>to rfc7366 so far?

As far as I know all deployed implementations until the recent ones (NSS,
PolarSSL) are compliant with RFC 7366.  What they aren't compliant with is an
interpretation that says "MAC the ciphertext and then another 20/32 bytes of
whatever follows the ciphertext", which is what the "include the MAC length"
interpretation seems to be doing.

More than a year ago when the drafts were published and people implemented
them, there were no interop problems, no-one complained about any issues, so
the draft was published as an RFC.  I'll make that point again, during the
entire time that it was a draft no-one informed me of any ambiguity in
interpretation or problems with interop in regard to this particular issue, if
they had I would have fixed them.

Now that it's an RFC, a new set of implementers have managed to come up with
an interpretation that, AFAICT (a) isn't in the RFC, and (b) doesn't make any
sense.  I could certainly issue a clarification, but first I'd have to
understand (a) how recent implementers are managing to come up with an
interpretation that isn't in the RFC and (b) what sort of wording to use to
correct this.

Peter.

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Thu, 30 Oct 2014 11:31:48 +0100

On 30/10/2014 10:40, Peter Gutmann wrote:
> PolarSSL) are compliant with RFC 7366.

Just to be clear: PolarSSL and GnuTLS are not deployed, and AFAIK (from the bug
report) neither is NSS. We make sure to test interop before releasing.

> What they aren't compliant with is an
It's not what it is doing, please see my email from 10:19 today (which you might
not have noticed before posting):

https://mailarchive.ietf.org/arch/msg/tls/uCqXIwnSC1mXlbkMFxFKpOtqbRk

> they had I would have fixed them.
I hear you. I honestly think it's just bad luck that nobody noticed before and
the early implementers just happened to spontaneously make the same
interpretation. I guess that's why there is an errata system.

> an interpretation that,

I can't speak for others, but I didn't "manage to come up with". That's the most
natural interpretation of the RFC to me. I'm aware it is not what you intended
the RFC to mean, and it is not how previous implementers read it, and that's
exactly why I want the RFC to be clarified.

We're on the same side here: we all want the RFC to be deployed and used soon.
That's why we want unambiguous text that reads the same way to everyone.

> AFAICT (a) isn't in the RFC, and (b) doesn't make any
> sense. 

Regarding (b), see the email cited above. Regarding (a), please answer to the
following questions based on the text of the RFC (assuming TLS 1.2 (not DTLS,
not TLS 1.0) for the sake of simplicity; byte numbers are 0-based).

1. What should be bytes 11 and 12 of the input to the MAC function?
2. What should go on the wire as bytes 3 and 4 of the record?

My understanding of the RFC is that the answer to both of these questions is
TLSCiphertext.length. For (1), my answer is based on:

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       TLSCipherText.length + // <----- bytes 11-12 of the MAC input
       IV +
       ENC(content + padding + padding_length));

For (2) it's based on:

   The overall TLS packet [2] is then:

   struct {
          ContentType type;
          ProtocolVersion version;
          uint16 length; // <----- bytes 3-4 on the wire
          GenericBlockCipher fragment;
          opaque MAC;
          } TLSCiphertext;

So, based on the text of the RFC, am I wrong saying that those two pairs of
bytes should have the same value? If so, please tell me exactly where I'm mistaken.

If I'm not wrong here, then the eid server is, because it does not use the same
value for these two pairs of bytes.

> I could certainly issue a clarification, but first I'd have to
Let's first agree on the answer to the above questions, then I'll be happy to
suggest wording.

Manuel.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 30 Oct 2014 13:12:10 +0200

> interpretation that isn't in the RFC and (b) what sort of wording to use to

I read relevant parts of RFC7366 and RFC5246. 

I got (perhaps weird) interpretation that this extension truly pulls the
MAC off ciphertext fragment.

Thus, the length field on _wire_ does _not_ include the MAC, and the
MAC'd data is what is on wire, bit for bit.

E.g. 14-byte application payload, minimal padding, AES-CBC, HMAC-SHA1,
TLS v1.2: 32 bytes, regardless of MAC truncation (whereas normally it
would be 52 for full and e.g. 48 for 16-byte truncated MAC).

What that sort of thing does to "middleboxes" that for some reason
parse the TLS PDU stream could be somewhat... interesting.

-Ilari

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Thu, 30 Oct 2014 12:34:34 +0100

> MAC'd data is what is on wire, bit for bit.
I think that's one possible way to read the RFC indeed. I'll just repeat what
Nikos said in [1]: this is _not_ what the eid server does.

https://www.ietf.org/mail-archive/web/tls/current/msg14345.html

> would be 52 for full and e.g. 48 for 16-byte truncated MAC).
And in this scenario, the eid server puts 52 (ie 00 34) on the wire. As does
every other implementation I know of.

Just to (try and) make sure the behaviour of the implementations discuss is
clear to everyone, the only difference between the two groups of implementation
I know of is that, in your example (thanks for making things concrete) is:

MAC( seq_num, type, version, 00 20, encrypted_stuff ) // eid, openssl

vs:

MAC( seq_num, type, version, 00 34, encrypted_stuff ) // nss, gnutls, polarssl

> parse the TLS PDU stream could be somewhat... interesting.
I think so. Even without considering middleboxes, this doesn't sound right, and
that's probably why no implementation does that, thought I agree that's one of
the conclusions that can be logically reached by strictly interpreting the RFC.

Manuel.