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

[Xuelei Fan <[e-mail]>]

On 4/3/2014 9:44 PM, Karthik Bhargavan wrote:
> We cannot modify Renegotiation Indication since TLS extensions are not
> versioned.
>
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 <[e-mail]
> <mailto:[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]>
>         <mailto:[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]>
>                      <mailto:lists@drh-consultancy.__co.uk
>         <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]> <mailto:[e-mail]
>         <mailto:[e-mail]>>
>         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>>
>
>
>
>
>
>         _________________________________________________
>         TLS mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/__listinfo/tls
>         <https://www.ietf.org/mailman/listinfo/tls>
>
>
>