Thanks, Peter, for the quick response. I'll hold the DISCUSS for now, for clerical purposes pending a revised I-D. On the "SHOULD" explanations, thanks for the explanations, and it'd be great if some version of them could get into the document.
Barry On Wed, Feb 18, 2015 at 5:12 PM, Peter Saint-Andre - &yet <pe...@andyet.net> wrote: > Hi Barry, thanks for the feedback. My comments inline (not coordinated with > my co-authors, who are in far-off timezones). > > On 2/18/15 5:16 PM, Barry Leiba wrote: >> >> 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. > > > Good point. We'll correct that in the revised I-D after tomorrow's telechat. > >> ---------------------------------------------------------------------- >> 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" ? > > > Yes, I think that's a much better way to express it. > >> How can I evaluate each of the following "SHOULD"s? Why might I have a >> good reason not to comply with each of them?: > > > Those are always good questions to ask. > >> -- Section 3.2 -- >> >> o When applicable, Web servers SHOULD use HSTS to indicate that they >> are willing to accept TLS-only clients. > > > Section 11.3 of RFC 6797 might provide a good reason (self-signed > certificates) in some circumstances. Other than the relative youth of RFC > 6797, I have not yet given more thought to other reasons. > > (BTW, it strikes me now that the phrase "when applicable" perhaps provides > unnecessary wiggle room.) > >> -- Section 3.3 -- >> >> Implementations and deployments SHOULD disable TLS-level compression >> ([RFC5246], Section 6.2.2). > > > Because it's not yet clear to me that all application protocols using TLS or > DTLS are subject to these compression-based attacks (at least, I have not > yet seen analysis of all the many such protocols), personally I would > hesitate at this time to say that all protocols MUST disable TLS-level > compression. > >> -- 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. > > > Some of those recommendations are not yet fully baked (e.g., binding the > master secret to the full handshake is described in > draft-ietf-tls-session-hash) or in the early stages of development (e.g., > RFC 5746 does not explicitly apply to abbreviated handshakes and the > triple-handshake authors say only that they propose to define a secure > resumption indication extension along the lines of RFC 5746) so it is > probably premature to say that they are best *current* practices. > >> -- 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. > > > I think that one would be fine as MUST (notice, however, that it applies to > a cipher suite that itself is a SHOULD). > >> 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. > > > Always a good idea. > >> --- >> >> 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" >> ? > > > Noted. > > Thanks again, > > Peter > > -- > Peter Saint-Andre > https://andyet.com/ > _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
