MSC4108: Mechanism to allow OAuth 2.0 API sign in and E2EE set up via QR code #4108
Conversation
hughns
changed the title
turt2live
added
proposal
|
finally, it is no longer just an idea presented at FOSDEM 🥳 |
hughns
force-pushed
the
element-hq/oidc-qr-login
branch
from
5cd815f to
177a2db
Compare
…org/matrix-spec-proposals into element-hq/oidc-qr-login
| This scheme is essentially [ECIES](https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme#Formal_description_of_ECIES) | ||
| instantiated with X25519, HKDF-SHA256 for the KDF and ChaCha20-Poly1305 (as specified by | ||
| [RFC8439](https://datatracker.ietf.org/doc/html/rfc8439#section-2.8)) for the authenticated encryption. Therefore, | ||
| existing security analyses of ECIES are applicable in this setting too. Nevertheless we include below a short | ||
| description of our instantiation of ECIES and discuss some potential pitfalls and attacks. |
There was a problem hiding this comment.
If we were designing this today, I'd use RFC 9180 HPKE instead. It's conceptually the same construct as ECIES but better specified, with better libraries, backed by the CFRG/IRTF and used in MLS.
hughns
changed the title
Make rendezvous API optional and return 404. Make authentication on creating rendezvous optional and return 403. Add client header filtering for unsafe content. Clean up for readability.
Clarify original thinking behind QR format. Add notes about versioning and unstable prefixes
| The QR codes to be displayed and scanned using this format will encode binary strings in the general form: | ||
|
|
||
| - the ASCII string `MATRIX` | ||
| - one byte indicating the QR code version (must be `0x02`) |
There was a problem hiding this comment.
What is the meaning and purpose of this field? What does the value 0x02 represent, i.e. what practical insight do you gain upon reading the value 0x02 in a message?
There was a problem hiding this comment.
This is the field in the current CS API, so I assume your question is directed at the current spec? In which case I will find out its origin.
There was a problem hiding this comment.
This QR code format seems to come from MSC1544. Original author was @uhoreg.
The line for version is https://github.com/matrix-org/matrix-spec-proposals/pull/1544/files#diff-fd371cd950df67f5a748e49d367ce76d81c216f62feaf870a714cf43413265b4R177 and appears without comment/discussion.
There was a problem hiding this comment.
My point is more that I don't see much of a relation between the existing spec QR code–using feature currently described in the spec (i.e. the verification flow using QR codes) and the feature described by this MSC (QR code login). They both happen to use QR codes but that's where the similarities stop; they are fundamentally different protocols.
Given that, I see literally no benefit in trying to nominally keep them part of the same thing, only potential downsides, such as confusion and mixing up one protocol's messages for the other. It also introduces a completely unnecessary dependency between two parts of the spec such that one cannot evolve independently of the other, since the "modes" are muxed together.
To exemplify:
MATRIX<0x2><0x1>andMATRIX<0x2><0x2>are QR verification flow messagesMATRIX<0x2><0x3>andMATRIX<0x2><0x4>are QR code login messages- Then at some later point we decide to evolve the QR code login protocol, and now we have
MATRIX<0x2><0x5>andMATRIX<0x2><0x6>as further QR code login messages, corresponding to v2 of the QR code login protocol - Then even later, we decide to evolve the QR verification flow, begetting
MATRIX<0x2><0x7>andMATRIX<0x2><0x8>as new QR verification flow messages, corresponding to v2 of the QR verification flow protocol - In which case, what conceivable meaning could ever be assigned to
MATRIX<0x3>?!
I think you can appreciate this is quite confusing. The original mistake is in trying to reuse the spec's QR code "format". In reality, MSC1544 doesn't describe a generic QR code format that we should strive to reuse. It describes an unrelated key verification protocol that happens to use QR codes and is currently on version 2.
| If a new version of this QR sign in capability is needed in future (perhaps with updated secure channel protocol) then | ||
| additional "mode" values can be added. |
There was a problem hiding this comment.
This feels like a hack. The modes were meant to encode directionality of the two participants, so it IMO makes little sense to add additional ones.
It can certainly be made to work for this particular case, but I'm beginning to wonder why this MSC does not have a single protocol versioning field. In light of https://github.com/matrix-org/matrix-spec-proposals/pull/4108/files#r2375468437, I believe the QR code version field should be clarified to be this missing protocol version field for the protocol described by this MSC.
turt2live
removed
matrix-2.0
turt2live
moved this from Ready for general review
to Proposed for FCP readiness
in Spec Core Team Workflow
This commits adds a Elliptic Curve Encryption Scheme, this scheme can be used in ephemeral situations where a full 3DH-based Olm session might be overkill or too hard to set up. The canonical example where this can be used is the QR code login feature in Matrix[1]. Co-authored-by: Denis Kasak <[email protected]> Co-authored-by: Hugh Nimmo-Smith <[email protected]> [1]: matrix-org/matrix-spec-proposals#4108
16 participants
Rendered
Dependencies:
Video demo:
The authors are employed by Element to write this MSC.
Major revisions
The is an older version of this proposal (referred to as "2024") that has some significant differences from the current proposal.
To help avoid confusion on the status, the following is hopefully helpful:
unstable_features.org.matrix.msc4108istruein/versionsresponse from homeserverThe high-level to-do list for the latest version:
Proof-of-MSC implementations
2024 version
Implementations for 2024 version:
Latest version
Implementations of this version are not available yet.