Re: [TLS] Resumption Contexts and 0-RTT Finished

Dear all,

Here is an extended summary of the early Finished / resumption context
discussion at the WG.

1. Signature forwarding with external PSK

Currently, resumption context is only defined for resumption-based PSK,
which means that external PSKs are not protected against transcript
synchronization attacks.

At a high level, this means that there is no crypographic binding between
the handshake log (what is signed for authentication) and the PSK used in
the key exchange.
In the resumption case, the resumption context fills this role (which is the
reason why it was introduced); however, all external PSKs currently have
their resumption context set to 0 (and thus, all logs are equivalent w.r.t.
all non-resumption PSK).
Since the handshake log is what get signed during certificate-based
authentication, the lack of binding
means that a signature from a session s1 can be used in a session s2 as long
as the PSK identifier are the same, which is a very weak constraint.

Before Cas Cremer's paper, this was particularly bad because the Finished
(which is bound cryptographically to the PSK) was not part of the handshake
log; therefore, all signatures could potentially be replayed.
However, even though Finished are now part of the log, the server signature
in PSK 1-RTT remains vulnerable (because the log is then ClientHello,
ServerHello, Certificate and thus has no Finished message to save us from
transcript synchronization). For those of you who were at TRON, you may
remember that Karthik made this point quite clearly in his talk (he even
proposed to swap CV and Finished for this very reason!).

An attack against external PSKs easily follows: we assume that an attacker A
wants to impersonate a server S to some
IoT-like client C that can only do pure PSK for key exchange. 

1. C registers to A under the PSK identifier Xc. The PSK between C and A is
Kca
2. A, acting as a client, registers to S under the same identifier Xc. The
PSK between A and S is Kas
3. C connects to A using (Xc, Kca). A forwards the ClientHello to S
4. S sends back ServerHello, [EE, Cert(S), CertVerify, Finished]_hs where hs
depends on Kas and the log [ClientHello, ServerHello]
5. A forwards ServerHello from S to A and re-encrypts [EE, Cert(S),
CertVerify] under hs' which depends on Kca and [ClientHello, ServerHello]
6. Since all logs are synchronized and nothing in the CertVerify depends on
Kca or Kas, C authenticates A as S.

2. Proposals to bind log and PSK

As pointed out by Karthik months ago (and by myself years ago, in the
context of Triple Handshake), implicit authentication (such as PSK or
resumption) is difficult to mix correctly with transcript-based signatures.

We have considered several ways to ensure uniform security for all PSK
modes.
The simplest solution (let's call it option A) is to rely on the draft 13
resumption context infrastructure also in the case of external PSK.
Put it simply, externally-provided PSKs are treated as if they were
resumption master secrets: if K is the external key, we first compute
Ek = extract(K, 0), then PSK=expand(Ek, "external psk") and RC=expand(Ek,
"external psk context").
Resumption context is renamed PSK context and PSK and RC are used as in the
current draft13 key schedule.

While option A does the job, we think it is over-complicated, as we observe
that the early finished can actually play exactly the same role as the
current resumption context (saving the concatenation with rc in every
expansion with an handshake log).

As an option B, we propose to always include an early finished in the log,
regardless of the handshake mode.
This comes with some complications that were discussed during the WG
meeting. Very notably, if this early finished is assumed to always come
after the ClientHello, then it must either a. mangled with the ClientHello
in an ugly way or b.send on the wire at all.
During the WG meeting, it was pointed out that regardless of whether a or b
is used, if the client proposes more than
one PSK, there needs to be more than one early finished.

I have thought more about this, and I now agree that this makes option B
unpractical.
We are left with some more options: one would be to swap CertificateVerify
and Finished, as Karthik originally suggested.
Another would be to have a Finished immediately after ServerHello. Neither
of these alternatives is particularly appealing,
and it may be the case that option A is in fact the better choice.

Best,

Antoine

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ilari Liusvaara
Sent: mardi 19 juillet 2016 15:46
To: tls@ietf.org
Subject: [TLS] Resumption Contexts and 0-RTT Finished

Thinking about this...

One option would be like 2 on the slides (the overstriked one!), except:

- The message is synthethized, not actually sent on wire (but still
  logged).
- It only happens after the last ClientHello.
- It uses the actual PSK, even if not #0.

Maybe I should have listened to the talk more carefully, but the reason I
got for overstriking the second option was that it is unimplementable in
practice.

Of course, dunno if the changes would actually fix the problems with PSK
contexts...

-Ilari

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls