Subject: [Uta] Barry Leiba's Discuss on draft-ietf-uta-tls-bcp-09: (with DISCUSS and COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Wed, 18 Feb 2015 16:16:43 -0800

Barry Leiba has entered the following ballot position for
draft-ietf-uta-tls-bcp-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

One very simple point:

-- Section 2 --

   A number of security-related terms in this document are used in the
   sense defined in [RFC4949].

Terminology definitions need to be in normative references; 4949 should
be normative.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I don't want to make these a DISCUSS, but I would appreciate a
discussion:

-- Section 3.1.1 --
On the SHOULD NOTs here: Is there any reason one might violate them
*other than* that the other side doesn't support TLS 1.2 ?  If not, is it
worth saying that explicitly?  Is it even worth changing "SHOULD NOT
negotiate TLS version [x]" to "MUST NOT negotiate TLS version [x] unless
no higher version is available in the negotiation" ? 

How can I evaluate each of the following "SHOULD"s?  Why might I have a
good reason not to comply with each of them?:

-- Section 3.2 --

   o  When applicable, Web servers SHOULD use HSTS to indicate that they
      are willing to accept TLS-only clients.

-- Section 3.3 --

   Implementations and deployments SHOULD disable TLS-level compression
   ([RFC5246], Section 6.2.2).

-- Section 3.5 --

   TLS clients
   SHOULD apply the same validation policy for all certificates received
   over a connection, bind the master secret to the full handshake, and
   bind the abbreviated session resumption handshake to the original
   full handshake.

-- Section 4.2.1 --

   Servers SHOULD prefer this cipher suite over weaker cipher suites
   whenever it is proposed, even if it is not the first proposal.

For the above set of "SHOULD" questions, I'm looking for something in the
document that can help readers understand why these are not "MUST", and
when and why they might make an informed decision not to abide by them.

---

One other non-blocking comment; no discussion needed:

-- Section 3.1.2 --
Nit: "correlates to Version 1.2 of TLS 1.2" -- take out one of the "1.2"
?