The technical results in my 2001 paper are correct but the conclusion
regarding SSL/TLS is wrong. I assumed that TLS was using fresh IVs and that
the MAC was computed on the encoded plaintext, i.e. Encode-Mac-Encrypt
while TLS is doing Mac-Encode-Encrypt which is exactly what my theoretical
example shows is insecure. The later padding attacks showed that the
theoretical example of insecurity had a very practical instantiation in
TLS.  While the paper shows correctly that MAC-then-Encrypt can be secure
with both CBC and stream ciphers, it also shows that it requires a LOT of
care about encoding - it turned out that TLS/SSL was not doing that. So if
you want to keep Mac-then-Encrypt then you must change the encoding as well
as how you apply the MAC. Changing to Encrypt-then-MAC is a much safer
solution.

Hugo




On Sat, Jun 7, 2014 at 9:15 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:

> Hi
>
> I’ve read the draft and I have a  few comments:
>
> The motivation for this extension is not clear from the draft. The
> introduction says that the MAC-then-encrypt construction is “no longer
> regarded as secure”, and that it has been the subject of “numerous security
> vulnerabilities and attacks”. For the latter claim, there are no references
> given either in the document itself or in references. For the former two
> articles are cited.
> The first (reference [5]) is by Hugo Krawczyk. While that article shows a
> theoretical weakness of MAC-then-encrypt, it also finds that (quoting from
> the abstract) “On the positive side we show that the
> authenticate-then-encrypt method is secure if the encryption method in use
> is either CBC mode (with an underlying secure block cipher) or a stream
> cipher (that xor the data with a random or pseudorandom pad).”. It also
> concludes that “the current practical implementations of [SSL] that use the
> above modes of encryption are safe”. So this is not a great call for action.
> The second (reference [6]) is a better reference, but I’m still missing a
> reference to anything practical or close to practical.
>
> The rationale for the mandate in section 3.1 is not clear to me. Sure, EtM
> is better than MtE, so renegotiating from MtE to EtM is a downgrade, but
> there is no mandate for implementations that are configured to support both
> algorithms to avoid downgrading from AES-256 to single DES, so why add this
> here?   Also, this section uses the terms “state”, “status” and “mechanism”
> seemingly interchangeably, and doesn’t explain why changing mechanism
> during renegotiation is a SHOULD NOT-level issue, or how AEAD ciphers
> figure in this mandate.
>
> One more thing, this time a nit: informative reference number 7 describes
> a document as “RFC xxxx”. This is a reference to
> “draft-bmoeller-tls-downgrade-scsv”, which according to the datatracker is
> an individual draft that nobody’s asked to publish yet. It should be
> referenced with the draft name as a work in progress. Since it’s an
> informative reference, this won’t block publication of this document.
>
> Yoav
>
> On Jun 6, 2014, at 5:52 PM, The IESG <iesg-secretary@ietf.org> wrote:
>
> >
> > The IESG has received a request from the Transport Layer Security WG
> > (tls) to consider the following document:
> > - 'Encrypt-then-MAC for TLS and DTLS'
> >  <draft-ietf-tls-encrypt-then-mac-02.txt> as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action. Please send substantive comments to the
> > ietf@ietf.org mailing lists by 2014-06-20. Exceptionally, comments may
> be
> > sent to iesg@ietf.org instead. In either case, please retain the
> > beginning of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> >   This document describes a means of negotiating the use of the
> >   encrypt-then-MAC security mechanism in place of TLS'/DTLS' existing
> >   MAC-then-encrypt one, which has been the subject of a number of
> >   security vulnerabilities over a period of many years.
> >
> >
> >
> >
> > The file can be obtained via
> > http://datatracker.ietf.org/doc/draft-ietf-tls-encrypt-then-mac/
> >
> > IESG discussion can be tracked via
> > http://datatracker.ietf.org/doc/draft-ietf-tls-encrypt-then-mac/ballot/
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> > ID nits found an Obsolete normative reference: "RFC 4366 (ref. '3')
> > (Obsoleted by RFC 5246, RFC 6066)" which will be replaced.
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>