Subject: [Uta] Stephen Farrell's Yes on draft-ietf-uta-tls-bcp-09: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Mon, 16 Feb 2015 13:40:28 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-uta-tls-bcp-09: Yes

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/

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

I've a bunch of nits below. The only non-bit is whether or
not this has recently been compared to bettercrypto.org.
Doing so again would be a fine thing if not.

- abstract & intro: nit: maybe s/and modes of
operation/and their modes of operation/ might be better,
as modes are defined by ciphersuites

- intro: maybe s/are/have been/ when you say CBC and RC4
are most common - that's changing fairly quickly

- intro: maybe s/will have/should have/ fewer vulns. when
deploying TLS1.3 - we can't control code quality

- 3.2: SSL stripping could do with a reference maybe

- 3.3: If it is true that compression attacks require the
attacker to control the traffic, then saying so would be
good, but only if there's an easily understood way to
phrase that, and I can't think of one right now;-)

- 3.6: add a reference to where SNI is defined (that's RFC
6066, section 3 I think?)

- section 4: would a reference to bettercrypto.org be good
here - they have specific configs one can use to implement
these recommendations (or at least I hope they do!)

- 4.1: I forget if the WG discussed adding a SHOULD NOT
for RSA key transport. I think that'd be a fine addition,
along with a statement that the justification is the lack
of PFS.

- 4.2.1: nitty, nit, nit: they MTI acronym should be
defined on 1st use, not 2nd:-)

- 4.4: "negotiated parameters" reads somewhat ambiguously
as it could be read to mean chinese menu, and I don't
think that's what you want

- 7.1: did anyone compare this text to the "most dangerous
code" paper? [1] [1]
http://dl.acm.org/citation.cfm?id=2382204

- 7.3: "aka PKIX certificates" isn't correct, I'd delete
the phrase (but leave the ref to 5280) both times