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 _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
