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

From: Nico Williams <[email-masked]>
Date: Mon, 3 Mar 2014 23:11:34 -0600

[Cross-posting to [email-masked].  Please drop one of tls or kitten
when responding.  For KITTEN readers, see the TLS list archives,
there's an MITM vulnerability when using tls-unique in conjunction
with session resumption.]

On Mon, Mar 3, 2014 at 4:07 PM, Adam Langley <[email-masked]> wrote:
> On Mon, Mar 3, 2014 at 4:07 PM, Andrei Popov <[email-masked]> wrote:
>> It appears that the attack described is only feasible when two
>> implementation defects are present:
>
> That's not an unreasonable characterisation of the renegotiation-based
> attacks, but the problem with tls-unique is more fundamental.

The problem for tls-unique is more fundamental indeed, and Andrei's
characterization is not applicable.

We should talk about how to fix tls-unique.  The best fix may be to
keep track of the original (non-resumed) connection's tls-unique CB
and add that to the resumed connection's tls-unique CB.  This requires
adding to the session cache on the client side.

In the short-term, client and server applications should not permit
session resumption prior to channel-bound authentication (if using
tls-unique).  Except that, of course, how is the application to know
if session resumption is involved?  Assuming that it can't know or
prevent the use of session resumption, I'd say that tls-unique is just
simply not to be used.  We should publish a new tls-unique that
doesn't have this problem.

Nico
--

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 4 Mar 2014 14:36:02 +0000

>with session resumption.]

Is it accurate to say that the threat with tls-server-endpoint is more
like the other cases discussed?

I'm much more concerned about that option, because tls-unique is
essentially unimplementable with most software anyway.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Tue, 4 Mar 2014 14:41:31 -0600

> like the other cases discussed?

Yes.  We should fix this too.

> essentially unimplementable with most software anyway.

I'm not so certain.  At any rate, the proposed fix of binding the
master secret of resumed sessions to the original session would fix
tls-unique, but not tls-server-end-point.

Nico
--

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 4 Mar 2014 21:54:45 +0000

>Yes.  We should fix this too.

Well, my point is, if the threat model with tls-server-endpoint is that
you have to not detect the change in the server certificate, I'm
reasonably comfortable with the scope of that issue as it stands now.
There may be broken stuff, but it should be fixable broken stuff.

"Fixing" that by making it impossible with off the shelf TLS code to do
channel binding would definitely not be a step forward.

It so happens that the somewhat hacky way I defined channel binding with
SAML is, I think, resistant to the cert changing (I'm still trying to
determine that for certain), but I do understand there's still an issue
there. Just doesn't seem anywhere near as bad as the tls-unique issue.

-- Scott