Subject: [TLS] Last Call: <draft-ietf-tls-encrypt-then-mac-02.txt> (Encrypt-then-MAC for TLS and DTLS) to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 06 Jun 2014 07:52:20 -0700

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
[email-masked] mailing lists by 2014-06-20. Exceptionally, comments may be
sent to [email-masked] 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.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 7 Jun 2014 16:15:13 +0300

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 <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Jun 2014 10:43:45 +0300

[adding draft address]

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 10 Jun 2014 11:01:32 -0400

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 <[email-masked]> wrote:

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

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Jun 2014 22:59:32 +0300

On Jun 10, 2014, at 6:01 PM, Hugo Krawczyk <[email-masked]> wrote:

> 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

Thanks

Yoav

---

From: [email-masked] (Martin Rex)
Date: Mon, 16 Jun 2014 17:34:55 +0200 (CEST)

> as how you apply the MAC. Changing to Encrypt-then-MAC is a much safer

I agree with you that your paper demonstrates problem with
mac-extend-encrypt schemes.  And that it fails to notice that
TLS applies CBC padding after computing the MAC and before encryption,
and is therefore an mac-extend-encrypt scheme that can be susceptible to
decryption oracles.

But I strongly disagree to the assertion that "Encrypt-then-MAC" would
be a much safer scheme than *TRUE* MAC-then-Encrypt _withou_ any
extension inserted before the encryption such as CBC-padding.

In fact, the pad-mac-encrypt scheme for TLS-CBC-ciphersuites, as suggested
by Serge Vaudenay, is provably safer than the currently favoured
encrypt-then-MAC scheme.

-Martin