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:[email protected]] On Behalf Of Ilari Liusvaara Sent: mardi 19 juillet 2016 15:46 To: [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
