On 03/14/2012 10:49 PM, Eric Rescorla wrote:
>
> However, unless I'm missing something, that doesn't apply here because
> the client sends the Certificate before the Finished, so the Finished
> is too late to detect tampering. The attacker can just simulate not
> having the extension, wait for the client Certificate, and then RST the
> connection instead of sending the Finished.
The ID says
> Consequently, static Diffie-Hellman SHOULD NOT be used with this document.
But really it's incompatible with all forms of Diffie-Hellman. Which
would seem to be a big step backwards compared to the current
capabilities of TLS.
Current TLS clients and servers can agree to pass client credentials
using authenticated encryption to cover a renegotiation handshake. This
method is not perfect, but it is widely used today. There should be some
discussion in the ID of exactly what is being gained by the new method.
Regardless, are there any examples of clients today that would refuse to
provide the client credentials if asked by an attacker on a
(not-yet-authenticated) initial handshake?
If not, perhaps a better first step would be standardizing a method (say
via a field in the x509 client cert itself) to inform the client TLS
stack that the cert MUST NOT be transmitted except as properly encrypted
to an authorized server.
- Marsh
_______________________________________________
TLS mailing list
TLS@...
https://www.ietf.org/mailman/listinfo/tls
