Clarify Key for PSKBinderEntry#1392
Conversation
|
This PR seems like a regression to me. ISTM that the current text is clear enough to provide interoperability. |
Are you saying that making it explicit makes the spec worse? |
| set of messages for authentication, key confirmation, and handshake | ||
| integrity: Certificate, CertificateVerify, and Finished. | ||
| (The PSK binders also perform key confirmation, in a | ||
| (The PSK binders also perform key confirmation and handshake integrity (via PSKBinderEntry), in a |
There was a problem hiding this comment.
PSKBinderEntry only provides partial handshake integrity and only sometimes. I don't think this helps.
There was a problem hiding this comment.
What exactly does "in a similar fashion" mean here?
There was a problem hiding this comment.
It means that like the Finished, they are a MAC computed over part of the Handshake transcript using a key tied to the PSK (as opposed to the Finished, which is tied to one of the traffic keys.
There was a problem hiding this comment.
This is still confusing for me. PSK binders are computed exactly the same way as Finished message. Finished message itself only provides handshake integrity and not the key confirmation. Key confirmation is provided by CertificateVerify message. So why is the key confirmation being mentioned here? or in other words, for which key is the PSK binder providing the key confirmation?
There was a problem hiding this comment.
The PSK binder is providing key confirmation for the PSK for which it is the binder. I.e., that the attacker didn't just attach a captured PSK ID to their ClientHello.
As for the Finished and key confirmation, I don't agree with you. The relevant key in this case is the session key, not the signature key. The Finished message is a MAC over the entire handshake using a key derived from the main secret.
There was a problem hiding this comment.
The Finished message is a MAC over the entire handshake using a key derived from the main secret.
I believe that's incorrect. First, the key for Finished is not derived from main secret. Doing so would have introduced cyclic dependency because the keys derived from main secret all take serverFinished and clientFinished as input in Derive-Secret. According to specs, the key for Finished is derived from handshake secret.
Yes, that's correct. My mistake.
Second, MAC is not over entire handshake. For example, the Finished message from Server can at best include handshake transcript up to CertificateVerify. It can neither include its own Finished message nor it can "predict" what Finished message Client will formulate on receiving this serverFinished message.
Yes, that's correct. I should have said "the handshake so far"
We may be talking past each other. So attempting to disambiguate this discussion: Taking a step back to the sentence just before the one under discussion (i.e., without PSK) just to explain where I was coming from:
In non-PSK-based handshakes, my understanding is that the three messages and three properties mentioned in that sentence have one-one relationship, i.e.: (with LTK = Long-Term Key)
* Certificate message provides _authentication_ via CA-signed certificate for public part of LTK.
This is an odd use of "authentication", because it doesn't actually authenticate the server at all. It just provides the binding of the LTK to the name.
* CertificateVerify message provides _key confirmation_ (proof-of-possession) for LTK (by signing the current handshake transcript with LTK).
No, I don't agree. In this context, "key confirmation" refers not to the LTK but rather to the shared secrets that were established as part of the handshake. I agree that as above, the Finished is derived from the HS secret, but that has the same underlying entropy as the main secret.
Moreover, CV provides more than just proof of possession of the LTK. It provides integrity for the handshake up to this point. Note that this is one of the key differences between TLS 1.2 and TLS 1.3
* Finished message provides _handshake integrity_ (by performing a MAC over the current handshake transcript with a key derived from handshake secret).
Yes, it provides this, but it also provides key confirmation for the aforementioned secret. This is all easiest to see if you analyze the handshake with a record layer that doesn't provide integrity or encryption (NULL ciphers). Without the Finished, at the end of the handshake neither side has any way of knowing that the peer has derived the right key.
Do you agree so far?
No, for the reasons above.
There was a problem hiding this comment.
To my knowledge, key confirmation is mostly used in the literature to provide proof of possession of LTK. But I see that it is used in section 2 in a way that is consistent with what you are saying. So, I agree with you. Reformulating it to be on the same page to wrap it up:
TLS generally uses a common
set of messages for authentication, key confirmation, and handshake
integrity: Certificate, CertificateVerify, and Finished.
Is the following correct interpretation of this sentence?
- Certificate message contributes to authentication.
- CertificateVerify message provides handshake integrity up to Certificate message by signing the current transcript hash by its LTK.
- Finished message provides handshake integrity and key confirmation for
finished_key.
This is an odd use of "authentication", because it doesn't actually authenticate the server at all. It just provides the binding of the LTK to the name.
Agree, Certificate by itself does not authenticate the peer. It only contributes to authentication.
In this context, "key confirmation" refers not to the LTK but rather to the shared secrets that were established as part of the handshake.
Thanks. I would appreciate an explicitly mention in Sec. 2.
I agree that as above, the Finished is derived from the HS secret, but that has the same underlying entropy as the main secret.
Agree. This is because there is no external secret between Handshake Secret and Main Secret (i.e., the IKM input for HKDF-Extract for Main Secret is 0), right?
This is all easiest to see if you analyze the handshake with a record layer that doesn't provide integrity or encryption (NULL ciphers).
That's very interesting. I am curious where in the spec I can find this case of NULL ciphers for record layer?
There was a problem hiding this comment.
@ekr could you please check if the above matches your understanding?
If you have some time, I would like to have a short chat with you in Madrid to wrap up both of my pending PRs. Thank you.
There was a problem hiding this comment.
Certificate message contributes to authentication.
I don't know what this means.
CertificateVerify message provides handshake integrity up to Certificate message by signing the current transcript hash by its LTK.
Yes.
Finished message provides handshake integrity and key confirmation for finished_key.
Yes, and transitively for the exchanged secrets.
The spec does not talk about NULL ciphers for the record layer. What I'm saying is that there have been analyses that do not take the handshake encryption into account.
I will not be in Madrid.
There was a problem hiding this comment.
Certificate message contributes to authentication.
I don't know what this means.
What exactly does authentication mean in the following sentence in the spec?
TLS generally uses a common
set of messages for authentication, key confirmation, and handshake
integrity: Certificate, CertificateVerify, and Finished.
More specifically, Certificate message has nothing to do with key confirmation and handshake integrity. Certificate alone also does not provide authentication. So I summarized it as: it contributes to authentication.
Finished message provides handshake integrity and key confirmation for finished_key.
Yes, and transitively for the exchanged secrets.
Sure, thanks.
The spec does not talk about NULL ciphers for the record layer. What I'm saying is that there have been analyses that do not take the handshake encryption into account.
Got it, thanks.
I will not be in Madrid.
oh that's a pity.
No, I'm saying it's incorrect. Sorry, I messed up the GitHub UI and failed to publish my review. |
muhammad-usama-sardar
changed the title
|
I think having it in Table 2 would have been best. But if you are really against calling it Finished key, this is a small clarification which makes it more explicit. |
|
|
||
| ~~~ | ||
| HKDF-Expand-Label(binder_key, "finished", "", Hash.length) | ||
| ~~~ |
There was a problem hiding this comment.
This is just the computation of the key for the entry, not of the value of the entry. You then need to compute the entry with HMAC over the transcript.
|
I have merged the specific clarification of which key is confirmed, minus the citation, which I don't think helps. I don't think that the explicit derivation of the finished key is that helpful, and as noted above, just having it alone is misleading. I'm open to adding something if there are other people who find this confusing, otherwise I'm inclined to leave it as-is. I'll leave this PR open until after Madrid if others have input. |
Works for me, thanks.
My feeling from 8773bis, draft-fossati-tls-attestation and previous formal analysis efforts was that both authors and verifiers, in general, have trouble with the key schedule. Having it explicit would be helpful for both. But if I am really the only one being confused here, I am okay with leaving it as-is.
Fine |
muhammad-usama-sardar
force-pushed
the
patch-2
branch
from
1e7d80c to
f4ea8c9
Compare
2 participants
Based on discussion on the list in the thread "Key Hierarchy TLS 1.3 RFC8446(bis)"