Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
draft-ietf-tls-encrypt-then-mac-03

[Ballot comment]
+1 to not bending over backward to accommodate SSLv3 :)

Section 3.
It would be helpful to note that the "+" symbol is being used to denote concatenation of octet strings, or use "||" as above.

[Ballot comment]
Thanks for including Section 2.1.  Also, I rather like the informal style (of Section 2.1, and of some other parts of the document).

-- Section 5 --

  IANA has added the extension code point 22 (0x16) for the
  encrypt_then_mac extension to the TLS ExtensionType values registry
  as specified in TLS [2].

This doesn't say whether there are or aren't any actions for IANA, and it should.  I think there actually is an action: to make the early-registration code point permanent.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-tls-encrypt-then-mac-02.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that upon approval of this document, there is a single action which IANA must complete.

In the ExtensionType Values registry in the Transport Layer Security (TLS) Extensions registry located at:

http://www.iana.org/assignments/tls-extensiontype-values/

the temporary registration for value 22 (encrypt_then_mac) will be made permanent and its reference changed to [ RFC-to-be ].

IANA understands that this is the only action required upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Encrypt-then-MAC for TLS and DTLS) to Proposed Standard


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

(1)

Proposed Standard; it's about interop; yes the type of RFC is indicated on the first page as well as in the datatracker.

(2)

Technical Summary

This document defines a means to negotiate the use of encrypt-then-MAC instead of the existing MAC-then-encrypt one.  WRT the existing mechanism, there are a number of identified vulnerabilities (see the references in the draft).

Working Group Summary:

This draft has been kicking around for a number of years and was adopted and progressed fairly quickly.  There were really just two debates 1) how to do the negotiation (see sec 2.1 of the draft), and 2) whether this applied to both stream and block ciphers (ended up applying to just block).

Document Quality

There's a test server up and running.  There's also a number of known implementations.

Personnel

Stephen Farrell is the responsible AD.
Sean Turner is the shepherd.

(3)

I read it, I reviewed the mailing list to make sure the issues raised during WGLC were addressed, I ran the ID-nit checker, and I updated the datatracker using the WG chair tools.  Oh and I also updated the replaced-by information.

(4)

None

(5)

No

(6)

I'm comfortable with the draft and you should be too.

(7)

Yes

(8)

No

(9)

Solid

(10)

No

(11)

ID-nits complains about an outdated normative reference to RFC 4366 which was obsoleted by RFC 6066.  I believe this warning can safely be ignored because implementers can find the Truncated HMAC extension for TLS 1.0 and 1.1 in RFC 4366 and can follow the references to RFC 6066 for TLS 1.2.

(12)

N/A

(13)

Yes

(14)

No

(15)

No

(16)

No

(17)

The IANA considerations section is fine.  We've asked for an early code point assignment based on the procedures in RFC 7120.

(18)

N/A

(19)

N/A