On 2/19/15 10:03 AM, Peter Saint-Andre - &yet wrote:
On 2/18/15 6:12 PM, Peter Saint-Andre - &yet wrote:
On 2/18/15 5:16 PM, Barry Leiba wrote:
<snip/>
-- 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.
The authors have been discussing this text. The problem is that some of
these recommendations are not yet deployable, and we have strenuously
avoided any forward-looking statements (no matter how tempting) in favor
of recommendations that can be considered current practices.
Thus I would propose the following text:
The most secure option for countering the Triple Handshake attack is
to refuse any change of certificates during renegotiation. In
addition, TLS clients SHOULD apply the same validation policy for all
certificates received over a connection. The [triple-handshake]
document suggests several other possible countermeasures, such as
binding the master secret to the full handshake (see
[I-D.ietf-tls-session-hash]) and binding the abbreviated session
resumption handshake to the original full handshake. Although the
latter two techniques are still under development and thus do not
qualify as current practices, those who implement and deploy TLS are
advised to watch for further development of appropriate
countermeasures.
Peter
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
