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

On Tue, Jul 19, 2016 at 4:45 PM, Antoine Delignat-Lavaud <
antoine@delignat-lavaud.fr> wrote:

> Dear all,
>
> Here is an extended summary of the early Finished / resumption context
> discussion at the WG.
>
>
Thanks for writing this up!

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

Note that this form of PSK + server signature isn't a mode we currently
specify
in TLS 1.3  However, given that the negotiation changes we discussed today
would in fact enable it, it seems like that would be something that's good
to fix
now.

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

I think this is the best option at this point.

-Ekr

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