Hi, standard people!
So I'm going to propose my third (and last) protoXEP [1] in EAX series
[2][3][4].
Since the editor is kinda busy these weeks, I'd like the Council to add
it to the upcoming agenda, since it's empty anyway :)
I see here and there some confusion on WTF I'm actually doing, so here
is a brief summary.
It's actually not about RELOAD. The idea is to build Public Key
Infrastructure (PKIX) based on X.509 certificates which is supposed to
be used in c2s SASL EXTERNAL and end-to-end authentication. So yeah, I
suggest to severely redesign authentication in the Jabber network and
move towards more p2p-ish architecture: will it be RELOAD or some kind
of roaming user profiles, doesn't matter that much, the point is to
slowly get rid of federation because it's a dead end in my opinion. In
particular, I suggest to eliminate SASL SCRAM family (it just sucks,
see my previous rants regarding SCRAM in this list and in the XSF
conference). The main problem was actually how to issue certificates
for XMPP clients. This is now specified in details in my last protoXEP
[1]. Note that the protoXEP also introduces new in-band registration
method: creating an account and issuing a certificate in a single step.
Ah, and this global authentication stuff is supposed to rely on a few
central fragile CA servers because we all love CAs :)
The use cases are outlined in XEP-0416 [2], but since nobody reads
intros, I'll copy them here (slightly modified):
1. E2E encryption
=================
For end-to-end encryption, XMPP clients may use certificates to
mutually identify each other, i.e. check that the cryptographic key
belongs to this exact XMPP address. This is supposed to resolve "verify
my OMEMO fingerprint" insanity we have today.
2. External services
====================
An XMPP server may authenticate users of other servers at its local
services, such as an HTTP Upload component, e.g. for granting file
uploads, or a STUN/TURN/SIP server. This is supposed to resolve
authentication on external services and provide an ability for clients
of abandoned servers to use services from other servers. In fact
anything that supports TLS may authenticate users using certs.
3. XMPP Usage of RELOAD
=======================
XMPP entities attached to the XOR overlay (XEP-0415 [3]) are supposed
to use certificates for mutual authentication. This is too complex and
somewhat unfinished, I'll address it later.
4. SPAM protection
==================
Since certificate authorities are required to be Sybil resistant [4], a
spammer is limited in ability to create accounts massively. Thus it is
expected that SPAM dissemination will fall to negligible levels. This
one is quite straightforward: let's finally eliminate SPAM. This time
for real.
5. Registration delegation
==========================
Managing freely available account registration at public servers is not
a simple task for operators of these servers. Failing to manage it
correctly leads to uncontrolled massive creation of accounts used for
SPAM propagation, DoS attacks, etc. and degrades the Jabber network as
a whole. A server operator may want to delegate a registration and
verification procedure to a trusted CA, which is supposed to be very
good at this task. The operator doesn't lose the userbase in this case:
user data and profiles are still located at the operator's server
(although I'm personally against siloing users for the sake of siloing
users).
6. Moved
========
The certificates can be used for e2e authentication needed during
moving an account from one server to another and it doesn't rely on any
support from the server a user is moving from. At least that's what I'm
told :)
Comments, criticism and hating are welcome! But before you're gonna
hating and ranting how bad CAs are (it actually depends on us in this
case), please provide alternatives for the outlined problems without
pretending those problems don't exist :)
[1] http://upload.zinid.ru/xep-eax-cir.html
[2] https://xmpp.org/extensions/xep-0416.html
[3] https://xmpp.org/extensions/xep-0415.html
[4] https://xmpp.org/extensions/inbox/eax-car.html#ca-reqs
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
