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
