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

[Karthik Bhargavan <[e-mail]>]

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 <[e-mail]> wrote:

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