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

[Manuel Pégourié-Gonnard <[e-mail]>]

On 30/10/2014 10:40, Peter Gutmann wrote:
> As far as I know all deployed implementations until the recent ones (NSS,
> 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
> 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.
> 
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

> 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.
> 
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.

> Now that it's an RFC, a new set of implementers have managed to come up with
> 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
> 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.
> 
Let's first agree on the answer to the above questions, then I'll be happy to
suggest wording.

Manuel.