From: Eric Rescorla [mailto:e...@rtfm.com] Sent: Saturday, March 25, 2017 6:40 AM To: Jim Schaad <i...@augustcellars.com> Cc: Russ Housley <hous...@vigilsec.com>; IETF TLS <tls@ietf.org> Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3 On Fri, Mar 24, 2017 at 8:14 PM, Jim Schaad <i...@augustcellars.com <mailto: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. It seems odd to me that you would want to use a different key agree algorithm when you are doing the initial negotiation as opposed to the resumption. Depending on how the static PSK is specified, it might need to be restated for the resumption as well. Jim -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 <mailto:tls-boun...@ietf.org> ] On Behalf Of Eric Rescorla Sent: Friday, March 24, 2017 12:19 PM To: Russ Housley <hous...@vigilsec.com <mailto:hous...@vigilsec.com> > Cc: IETF TLS <tls@ietf.org <mailto: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 <mailto: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
