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

From: Xuelei Fan <[email-masked]>
Date: Thu, 03 Apr 2014 21:32:46 +0800

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 <[email-masked]
> <mailto:[email-masked]>> 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
>             <[email-masked]
>             <mailto:[email-masked]>> 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
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/tls
>     <https://www.ietf.org/mailman/listinfo/tls>
>
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Karthik Bhargavan <[email-masked]>
Date: Thu, 3 Apr 2014 15:44:55 +0200

We cannot modify Renegotiation Indication since TLS extensions are not
versioned.

But we do have another internet draft called Secure Resumption Indication
that does this.
Specifically, it takes the session hash of the initial handshake that set
up a session and sends it within an extension in the hello messages of the
abbreviated handshake.
This would indeed fix the renegotiation attack and it would fix tls-unique,
but note that it would not fix master-secret based channel bindings (e.g.
PEAP).

Best,
Karthik

On Thu, Apr 3, 2014 at 3:32 PM, Xuelei Fan <[email-masked]> wrote:

> 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.
>

---

From: Xuelei Fan <[email-masked]>
Date: Thu, 03 Apr 2014 21:56:54 +0800

> We cannot modify Renegotiation Indication since TLS extensions are not
Sure, need to use a new extension ID.

> But we do have another internet draft called Secure Resumption
> Indication that does this.
> Specifically, it takes the session hash of the initial handshake that
> set up a session and sends it within an extension in the hello messages
> of the abbreviated handshake.
Is it published?  Can I have the link of the draft?

Thanks & Regards,
Xuelei

> This would indeed fix the renegotiation attack and it would fix
> tls-unique, but note that it would not fix master-secret based channel
> bindings (e.g. PEAP).
>
> Best,
> Karthik
>
>
>
>
> On Thu, Apr 3, 2014 at 3:32 PM, Xuelei Fan <[email-masked]
>     I was wondering, can an extension of the renegotiation indication
>     (RFC 5746) be used to bind the client and server?
>
>     "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.
>
>         On Wed, Mar 5, 2014 at 5:09 AM, Xuelei Fan
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>__>
>         wrote:
>
>         <mailto:[email-masked]>
>                      <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>
>
>              ___________________________________________________
>              TLS mailing list
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         https://www.ietf.org/mailman/____listinfo/tls
>         <https://www.ietf.org/mailman/__listinfo/tls>
>              <https://www.ietf.org/mailman/__listinfo/tls
>         <https://www.ietf.org/mailman/listinfo/tls>>
>
>
>
>
>