[adding draft address]
On Jun 7, 2014, at 4:15 PM, Yoav Nir <ynir(_dot_)ietf(_at_)gmail(_dot_)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(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org mailing lists by 2014-06-20. Exceptionally,
comments may be
sent to iesg(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/tls