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

From: Peter Gutmann <[email-masked]>
Date: Wed, 29 Oct 2014 13:21:12 +0000

Manuel Pégourié-Gonnard <[email-masked]> writes:

>My implementation does not interoperate with the one at eid.wx4.net either,
>when I enable EtM (fails with a bad_record_mac alert).

So what are people doing to get this?  Ages ago when the draft was first
published a bunch of implementations interop'd with this, so I wonder what's
changed?

Peter.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 29 Oct 2014 14:46:12 +0100

> published a bunch of implementations interop'd with this, so I wonder what's

I believe the description of Manuel and the NSS one [0] are pretty
clear. If that bunch of implementations interoperates with eid.wx4.net
then they don't follow the text in rfc7366. If the text is wrong and
these implementations correct an errata should be submitted to the RFC.

[0]. https://bugzilla.mozilla.org/show_bug.cgi?id=972145

regards,
Nikos

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Wed, 29 Oct 2014 14:59:12 +0100

On 29/10/2014 14:21, Peter Gutmann wrote:
> So what are people doing to get this?

What I'm doing to get this is interpret TLSCipherText.length exactly as it is
defined in RFC 5246 (6.2.3.2, page 22):

   The encrypted data length (TLSCiphertext.length) is one more than the
   sum of SecurityParameters.block_length, TLSCompressed.length,
   SecurityParameters.mac_length, and padding_length.

Apparently to interoperate with the implementation at eid.vx4.net (and with
OpenSSL 1.1.0-dev) one needs to rather interpret it as excluding
SecurityParameters.mac_length. I couldn't find this explicitly stated anywhere.

I strongly agree with Nikos that an erratum should make this explicit if that
was the intention of the document. (Or if this was not the original intention
but you prefer to align on the implementation(s) already deployed to avoid an
interop nightmare.)

Manuel.

---

From: "Christian Kahlo" <[email-masked]>
Date: Thu, 30 Oct 2014 13:25:09 +0100

Hi there,

I didn't change anything in the record structure or the handshake
behaviour. The only change is the new code point assignment for
the extension.

But as stated before I'll have a look in the final RFC and compare
it to the currently deployed implementation.

It would help to get handshake logs to see what happened on the
other end.

It is also possible to activate full debug mode and check for
interop issues.

Sorry, this didn't came to my attention until now. But it's
high prio now.

Best regards,
Christian

> -----Ursprüngliche Nachricht-----
> Von: Peter Gutmann [mailto:[email-masked]]
> Gesendet: Mittwoch, 29. Oktober 2014 14:21
> An: <[email-masked]>; Manuel Pégourié-Gonnard; Christian Kahlo
> Betreff: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
> 
> >My implementation does not interoperate with the one at eid.wx4.net
> >either, when I enable EtM (fails with a bad_record_mac alert).
> 
> So what are people doing to get this?  Ages ago when the draft was
> first published a bunch of implementations interop'd with this, so I
> wonder what's changed?
> 
> Peter.

---

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

Hi Christian,

and thanks for joining the discussion.

> It would help to get handshake logs to see what happened on the
As someone who has first written an incompatible implementation and then changed
it to be compatible, I think what happened is clear enough.

Oh, and I see while writing that Peter has been faster than me on the second
thing I wanted to tell: it's probably better to clarify the RFC first and only
later change the implementations that need to be changed to match the clarified
version.

Manuel.