Eric Rescorla wrote:
>
> On Wed, Mar 14, 2012 at 7:38 PM, Martin Rex <
mrex@...> wrote:
> >
> > As long as clients can be forced to downgrade, that special case
> > continues to exist.o
>
> I'm not really interested in relitigating the SCSV-vs-extension issue, but
> in the specific case of client identity protection, I don't see how SCSV
> provides rollback protection. The reason that the SCSV is (generally)
> less susceptible to rollback than extensions is that an attacker can
> simulate being un-extension-capable and and force the client into
> trying a non-extension handshake without breaking the Finished,
> whereas there aren't SCSV-intolerant servers, so the Finished
> detects SCSV removal.
Correct. If both, client and server offer a feature that is considered
worth having, the protocol should be resilient to attackers that want
the connection to be established without that feature.
>
> 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.
Unless I'm missing something: The key exchange is authenticated with the
server credential/certificate, and the client certificate will be
encrypted under ephemeral keys derived from that authenticated key exchange.
So an attacker can only get at the credential when he can either fully
impersonate the server or entice the client to connect (and send that
credential) to an entirely different server.
-Martin
_______________________________________________
TLS mailing list
TLS@...
https://www.ietf.org/mailman/listinfo/tls
