Subject: [TLS] Comments on draft-ietf-tls-encrypt-then-mac

From: Eric Rescorla <[email-masked]>
Date: Fri, 11 Apr 2014 10:00:39 -0700

I have just reviewed Peter's revised draft-ietf-tls-encrypt-then-mac
document.

Generally, I think this is ready to go.

I found the following issues which I think should be resolved prior to
publication:

1. The code point is listed as 21 in two locations, but that has been
 provisionally assigned to the padding extension. I suggest that you
 change this to the next open number, which is 22. The WG could
 probably ask for a provisional assignment, but given that this is
 the only major extension document in process and it will be going
 to the IESG soon, I don't think that that's necessary.

2. IMO you should point to draft-moeller in the Security Considerations.

3. Section 3.1 mentions an interop server. I wonder if this should be
removed prior to publication unless it is intended to stay up forever.

4. It would probably be useful to include syntax for DTLS in Section 3.

5. Is Section 3.1 intended to say that you MUST NOT negotiate backwards?
That seems OK, but you should probably say this explicitly.

6. Section 5 should have a placeholder for IANA's extension definition.
Something like:

"IANA [should allocate/has allocated] extension number 22 (0x16) for this
extensions."

(This is how we conventionally signal which code point we want).

7. In Section 3, it might be useful to call back to the TLS specification
which
describes how the connection must fail. E.g.,

"For TLS, a fatal bad_record_mac MUST be generated (see RFC 5246
Section 7.2.2). For DTLS, the record MUST be discarded and a fatal
bad_record_mac MAY be generated, as described in RFC 6347 Section 4.1.2.1)

-Ekr