Barry, following up, here is some proposed text (again, not yet
coordinated with my co-authors).
On 2/18/15 6:12 PM, Peter Saint-Andre - &yet wrote:
On 2/18/15 5:16 PM, Barry Leiba wrote:
<snip/>
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.)
OLD
o When applicable, Web servers SHOULD use HSTS to indicate that they
are willing to accept TLS-only clients.
NEW
o Web servers SHOULD use HSTS to indicate that they are willing to
accept TLS-only clients, unless they are deployed in such a way
that using HSTS would in fact weaken overall security (e.g., it
can be problematic to use HSTS with self-signed certificates, as
described in Section 11.3 of [RFC6797]).
-- 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.
OLD
Implementations and deployments SHOULD disable TLS-level compression
([RFC5246], Section 6.2.2).
NEW
In order to help prevent compression-related attacks (summarized in
Section 2.6 of [RFC7457]), implementations and deployments SHOULD
disable TLS-level compression ([RFC5246], Section 6.2.2), unless the
application protocol in question has not been shown to be open to
such attacks.
-- 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.
OLD
To counter the Triple Handshake attack, the recommended
countermeasures from [triple-handshake] are adopted: 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. In some usages, the most secure option might be to
refuse any change of certificates during renegotiation.
NEW
To counter the Triple Handshake attack, the recommended
countermeasures from [triple-handshake] are adopted: TLS clients
SHOULD apply the same validation policy for all certificates received
over a connection, SHOULD bind the master secret to the full
handshake (one emerging approach is documented in
[I-D.ietf-tls-session-hash]), and if possible SHOULD bind the
abbreviated session resumption handshake to the original full
handshake (although no standardized method for this has been defined
as yet). Although some of these methods are still under development,
those who implement and deploy TLS are advised to watch for further
improvements in these technologies. If none of these countermeasures
are available, the most secure option is to refuse any change of
certificates during renegotiation.
Peter
--
Peter Saint-Andre
https://andyet.com/
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
