Martin Thomson wrote: > This is a good idea. +1
> Just to highlight this point: if we need to add a PQ key exchange, > there is no guarantee that it will have exactly the same properties as > the key exchange methods we have today. I expect that need to arise > relatively soon, so that's an extra good reason to make this change. For the same reason, I think the labels for these new Derive-Secret calls should anticipate extensions that provide additional input secrets. This PR specifies labels for the PSK and (EC)DHE inputs Derive-Secret(., "derived early secret", "") Derive-Secret(., "derived handshake secret", ""), but the draft seems to allow arbitrarily many input secrets. Just above the diagram it says "Given a set of n InputSecrets, the final "master secret" is computed by iteratively invoking HKDF-Extract with InputSecret_1, InputSecret_2, etc." So we might want the labels in the new Derive-Secret calls to indicate which InputSecret is being incorporated, e.g. Derive-Secret(., "derived secret 1", "") Derive-Secret(., "derived secret 2", "") Derive-Secret(., "derived secret 3", "") etc. I should also note that the draft does not specify how an extension would produce an additional input secret. So, alternatively, we could just strike out the "Given a set of n InputSecrets" line. I personally think there should be a way for extensions to provide additional input secrets. I can submit a PR along those lines if there is interest. -John _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
