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

[Nikos Mavrogiannopoulos <[e-mail]>]

On Thu, 2014-11-06 at 01:36 +0100, Martin Rex wrote:

> > Really? Could you please elaborate on why you think the proposed fixes in [1]
> > (undoubling the doubled paragraph) and [2] are not correct fixes suitable for an
> > erratum?
> > [1] http://mailarchive.ietf.org/arch/msg/tls/3NOHlIUShLo9AAzXx4t2u7QV8Sw
> > [2] http://mailarchive.ietf.org/arch/msg/tls/zYBKe9L9n3tNZ_SBWn77ubLzNPs
> I had included the rationale in the mail from which you quote above:
> >>
> >> It doesn't really matter whether the seriously misleading and
> >> backwards-incompatible protocol in rfc7366 could be hacked to
> >> produce the same "bits-on-the-wire" as what was actually intended
> >> protocol-wise, by frobbing the semantics and content of the
> >> length field of the redefined rfc7366 TLSCiphertext and frobbing
> >> the MAC computation.
> It would be like publishing
>    2+2 = 5
> and then posting an errata that says
>    ...provided that the first instance of "2" is sufficiently close to "3".

No point in arguing about that. No text is perfect. Given that this
document is the only way to fix the issues with the cbc ciphersuites for
tls >= 1.1, it must be corrected one way or another. That is because it
is the only way to provide reasonable security for implementations which
do TLS 1.1 and don't have any other choice (such as the GCM
ciphersuites). If you think additional text is required please propose
it.

regards,
Nikos