Looks nice. Thanks for working this out. b
On Thursday, February 19, 2015, Peter Saint-Andre - &yet <[email protected]> wrote: > 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 [email protected] https://www.ietf.org/mailman/listinfo/uta
