-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update the exchange match logic to align with the latest spec proposal #8441
Update the exchange match logic to align with the latest spec proposal #8441
Conversation
Discussed with Boris and Martin, actions should be taken on the spec side first. |
@turon could you confirm if the change in this PR aligned with your proposal in spec? |
The new patch resolves my concern, but I still think comparing I'm considering remove all |
I agree. Does this block this PR, or do we want to write some TODO tickets? When messages come in the door, we have:
Obviously session ID is the primary key we should be using to recover internal context. Perhaps source ID and destination ID are also OK to pass to higher levels of the stack. But allowing higher level code to key on anything else seems like a good way to inadvertently create security vulnerabilities. |
The spec change(CHIP-Specifications/connectedhomeip-spec#3588) has specified how should we identify an exchange. The logic in the PR is implemented against the spec except comparing the |
Just as a minor correction: for unicast encrypted messages, spec does not send a source id and destination id at all. They are recoverable (and recovered) from the session id. |
Yes, this needs to be addressed in (CHIP-Specifications/connectedhomeip-spec#3588) as well. What's proposed there doesn't make sense. The session ID is an abstraction that, from the perspective of a recipient, can map to a subject. But the subject may or may not be a fabric+node identity. In the case of a PASE session, it isn't. If exchanges can exist over PASE, then keying on fabric+node identity doesn't work. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code is attempting session match based upon the peer key ID. That's not guaranteed unique and not secure.
Session ID is the local key ID, and this is what should be used to verify session match.
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Hold until https://github.com/CHIP-Specifications/connectedhomeip-spec/pull/3588 is resolved |
Removing SDK Discussion required, this doesn't require anything beyond the normal PR approval process. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks fine to me. I'd like to rename SecureSessionHandle
to SessionHandle
Thanks, that is already part of this change. |
Temporarily keep the old logic, check why only those two fields are used in comparison.connectedhomeip/src/transport/SessionHandle.h Lines 44 to 54 in e715539
This comment was generated by todo based on a
|
Size increase report for "gn_qpg-example-build" from 0bdeccb
Full report output
|
Size increase report for "esp32-example-build" from 0bdeccb
Full report output
|
Size increase report for "nrfconnect-example-build" from 0bdeccb
Full report output
|
project-chip#8441) * Update the exchange match logic to align with the latest spec proposal * Rename SecureSessionHandle to SessionHandle * Make mLocalKeyId and mPeerKeyId optional * Rename match to matchIncomingSession
Problem
What is being fixed?
After discussion, we agree to update spec with the following changes.
Change overview
Testing
How was this tested? (at least one bullet point required)
confirm the echo test pass with this change.
confirm the im test pass with this change.