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

From: Peter Gutmann <[email-masked]>
Date: Wed, 29 Oct 2014 14:20:14 +0000

Nikos Mavrogiannopoulos <[email-masked]> writes:

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

... or eid.wx4.net was changed after the interop took place, or the RFC text
was changed after the interop took place.  If you look at the original text,
it specifies:

  TLSCompressed.length

while the final version specifies:

  TLSCipherText.length

which may be the cause of the problem.  This was introduced in -04, long after
the interop tests had been done.  I'll have to dig through email to see why
this happened...

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 29 Oct 2014 14:32:30 +0000

>follow the text in rfc7366.

I'm still not clear how NSS interprets this in the way it does.
TLSCipherText.length is the length of ENC(content + padding + padding_length),
which from section 6.2.3 of RFC 5246 is now the same as TLSCipherText.fragment
(since the MAC isn't part of GenericWhateverCipher any more).  So whether you
pass in TLSCipherText.length (as per the RFC) or TLSCipherText.fragment (as
NSS does) shouldn't make any difference because they're the same thing.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 30 Oct 2014 16:17:21 +0000

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

>Another (related) idea: explicitly change the definition of
>GenericBlockCipher when EtM is in use

Henrick had suggested something like that as well, but at that point you're
starting to rewrite chunks of the main TLS RFCs, which may be overkill if the
goal is merely to explain which length value to use.  That is, it's valuable
for a future RFC (e.g. TLS 1.3) where you'd explicitly want to make this the
standard record format, but it may be a bit heavy going for an erratum that's
only supposed to say "use this value for the length".

The ideal explanation would be as short and concise as possible, and one where
no-one has any concerns about different interpretations.  This was why I was
leaning towards the "for the avoidance of any doubt ..." style of annotation,
it's a brief clarification to the existing text to clear up ambiguity.  My
concern is that adding a complex technical definition, while very precise, may
then require another erratum later on to explain it.

If anyone can come up with a clear one-paragraph note (which, when posted to
the list, no-one complains about :-), I'd be happy to use that.

Peter.