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

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

On 30/10/2014 12:12, Ilari Liusvaara wrote:
> Thus, the length field on _wire_ does _not_ include the MAC, and the
> 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

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

> What that sort of thing does to "middleboxes" that for some reason
> 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.