Re: [TLS] MITM Attacks on Client Authentication after Resumption

[Xuelei Fan <[e-mail]>]

I was wondering, can an extension of the renegotiation indication (RFC 
5746) be used to bind the client and server?

At present, in session resumption initial handshake, the 
"renegotiation_info" should be empty in both ClientHello and ServerHello 
messages.

In order to bind the client and server more tightly, the renegotiation 
indication can be extended to use the previous client_verify_data and 
server_verify_data in session resumption initial handshake (probably 
only if previous connection supports secure renegotiation).  That's, in 
session resumption initial handshake, client sends previous 
client_verify_data and server responses with previous client_verify_data 
plus server_verify_data.

This extension of the renegotiation indication need to cache 
client_verify_data and server_verify_data.

Regards,
Xuelei

On 3/5/2014 9:09 PM, Karthik Bhargavan wrote:
> After my talk at the meeting, its worth summarizing comments on the
> triple handshake attack and its impact on client-authenticated TLS
> renegotiation.
>
> In the common case (e.g HTTPS) where a server presents  a certificate in
> both the initial handshake and during renegotiation, it would be enough
> for the client to verify that the certificate doesn't change. (More
> precisely, the client needs to verify that the principals represented by
> both certificates are equally trustworthy.)
>
> There are other cases, and I'd be curious to know how common they are,
> when one or both handshakes does not have a server certificate. These
> would be more difficult to fix with a general TLS library-level policy.
>
> Typical examples (from discussion at the meeting):
>
> - Initial handshake uses DH_anon or a self-signed server cert
>    and renegotiation uses the real server certificate
> - Initial handshake uses a server certificate,
>    and renegotiation uses PSK or SRP to authenticate the user
>
> In the first case, I guess the purpose is to protect the server name
> from passive attackers. In the second, the purpose is privacy for the
> user's SRP/PSK identity.
>
> In both cases, if both handshakes happen on the same connection, RFC5746
> (renego indication) gives us a pretty strong guarantee that the
> principals on both ends do not change. In effect, the second handshake
> retroactively authenticates the first.
>
> The triple handshake attack shows that this nice guarantee does not hold
> if there is session resumption between the two handshakes.
>
> I can't think of easy implementation-level ways of fixing the DH_anon
> and PSK/SRP cases.
>
> Best,
> Karthik
>
>
>
> On Wed, Mar 5, 2014 at 5:09 AM, Xuelei Fan <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     On 3/5/2014 12:05 AM, Dr Stephen Henson wrote:
>
>         On 04/03/2014 15:23, Martin Thomson wrote:
>
>             On 4 March 2014 14:03, Dr Stephen Henson
>             <[e-mail]
>             <mailto:[e-mail]>> wrote:
>
>
>                 I performed a few checks with an experimental option to
>                 change the server
>                 certificate during renegotiation, which I believe
>                 simulates the attack
>                 mechanism. If the client checks certificates in band
>                 then all versions choke
>                 with a verification error if a chain is untrusted. For
>                 1.0.2 only it also chokes
>                 if the chain is trusted but the hostname doesn't match.
>
>
>             This is an interesting option.  I like the general idea, but
>             wonder
>             what "hostname doesn't match" means in this case.
>
>     JSSE enabled the hostname checking during handshaking for HTTPS and
>     LDAP.  If hostname doesn't match, the handshaking is terminated
>     immediately.
>
>
>         I'd be interested if anyone knows of examples where the server
>         certificate does
>         have to change during renegotiation and how common that practice is.
>
>     I was wondering, if the cipher suite is changed from RSA cert based
>     to EC cert based (and vice versa), the server certificate would have
>     to change accordingly.  Not sure about the case in practice.
>
>     Xuelei
>
>
>     _________________________________________________
>     TLS mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/__listinfo/tls
>     <https://www.ietf.org/mailman/listinfo/tls>
>
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>