On Fri, Mar 24, 2017 at 8:14 PM, Jim Schaad <i...@augustcellars.com> wrote:
> EKR – I think that is the wrong answer because of the resume case. > Why? It seems like for Russ'a application, you would inject the static PSK initially and then it would be implicitly part of any resumption so no need to reinject it to obtain PQ safety. -Ekr However, I would expect that the external PSK would be appended or > otherwise munge into the computed secret (assuming DH) and would be > consumed as part of that processing. No additional slot needed. > > > > jim > > > > *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* Friday, March 24, 2017 12:19 PM > *To:* Russ Housley <hous...@vigilsec.com> > *Cc:* IETF TLS <tls@ietf.org> > *Subject:* Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3 > > > > Why would the external PSK not just go into he PSK slot. > > > > -Ekr > > > > > > On Fri, Mar 24, 2017 at 9:16 AM, Russ Housley <hous...@vigilsec.com> > wrote: > > > > I agree with David here. Specifically, I think. > > > > - The base specification should continue to forbid certificates in > combination with PSK > > - We should at some point contemplate an extension that allows the use > of certificates in combination with PSK > > - The base spec should be factored in such a way as to make that > extension easy. > > > While I agree that we do not want to delay the TLS 1.3 specification to > sort this out; however, I do not think we have provided the hook to make > this future extension easy. Looking at the key schedule in -19, I think > we can provide the hook without being disruptive. My goal is to minimize > the pain to implementing the extension in the future by putting a > straightforward hook in today: > > 0 > | > v > PSK -> HKDF-Extract = Early Secret > | > +-----> Derive-Secret(., > | "external psk binder key" | > | "resumption psk binder key", > | "") > | = binder_key > | > +-----> Derive-Secret(., "client early traffic secret", > | ClientHello) > | = client_early_traffic_secret > | > +-----> Derive-Secret(., "early exporter master secret", > | ClientHello) > | = early_exporter_secret > v > Derive-Secret(., "derived secret", "") > | > v > (EC)DHE -> HKDF-Extract = Handshake Secret > | > +-----> Derive-Secret(., "client handshake traffic > secret", > | ClientHello...ServerHello) > | = client_handshake_traffic_secret > | > +-----> Derive-Secret(., "server handshake traffic > secret", > | ClientHello...ServerHello) > | = server_handshake_traffic_secret > v > Derive-Secret(., "derived secret", "") > | > v > ExtPSK OR 0 -> HKDF-Extract = Master Secret > | > +-----> Derive-Secret(., "client application traffic > secret", > | ClientHello...Server Finished) > | = client_traffic_secret_0 > | > +-----> Derive-Secret(., "server application traffic > secret", > | ClientHello...Server Finished) > | = server_traffic_secret_0 > | > +-----> Derive-Secret(., "exporter master secret", > | ClientHello...Server Finished) > | = exporter_secret > | > +-----> Derive-Secret(., "resumption master secret", > ClientHello...Client Finished) > = resumption_master_secret > > > The only change is "ExtPSK OR 0” in the HKDF-Extract for the Master Secret > computation. > > The Section 4.1.1 can call out this place for the future specification: > > OLD: > > - When authenticating via a certificate, the server will send the > Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3) > messages. In TLS 1.3 as defined by this document, either a PSK or > a certificate is always used, but not both. Future documents may > define how to use them together. > > NEW: > > - When authenticating via a certificate, the server will send the > Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3) > messages. In TLS 1.3 as defined by this document, either a PSK or > a certificate is always used, but not both. So, the ExtPSK is not > used in the key schedule (Section 7.1). Future documents may > define how to use them together and tell how the ExtPSK is > handled in the key schedule. > > Russ > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
