Re: Proposed XMPP Extension: XMPP Decentralized ID (XID)

--===============0649092129829515345==
Content-Type: multipart/alternative; boundary="000000000000ca1c29065344411e"

--000000000000ca1c29065344411e
Content-Type: text/plain; charset="UTF-8"

Repeating my GH comment verbatim:

This generally looks good, and I support publication.

Blockers for advancement:

* I don't think you can use the internal TLD here. That's a free-for-all on
private networks, and in cases where a XID is confused with a JID (since
they share the same syntax) it could end up resolving to an actual XMPP
server. Does the syntax for a XID have to match that of a jid? If so, I'd
suggest that the XSF creates a xid.xmpp.org domain for this purpose, with
zero'd SRV records.
* The challenge protocol is trivially MITMable. I suggest including the
source jid within the signed payload, and possibly signing the challenge
with the source XID too. This would mean that the challenge was mutual, and
mutually verifiable, though not end-to-end of course.

Four notes:

* I would strongly consider adding an expiry to the XID publication.
* I would also explicitly allow multiple XIDs - perhaps this is in place
already, I didn't notice it (but haven't exhaustively searched).
* I would also highly recommend examining PQ options (presumably KEM or
HPKI based) and also threshold cryptography might be interesting as well.
* By way of another approach worth examining, I'd suggest looking at Philip
Hallam-Baker's Mesh and its id service, callsigns:
https://datatracker.ietf.org/doc/html/draft-hallambaker-mesh-callsign-01

Dave.

--000000000000ca1c29065344411e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Repeating my GH comment verbatim:<div><br>This generally l=
ooks good, and I support publication.<br><br>Blockers for advancement:<br><=
br>* I don&#39;t think you can use the internal TLD here. That&#39;s a free=
-for-all on private networks, and in cases where a XID is confused with a J=
ID (since they share the same syntax) it could end up resolving to an actua=
l XMPP server. Does the syntax for a XID have to match that of a jid? If so=
, I&#39;d suggest that the XSF creates a <a href=3D"http://xid.xmpp.org">xi=
d.xmpp.org</a> domain for this purpose, with zero&#39;d SRV records.<br>* T=
he challenge protocol is trivially MITMable. I suggest including the source=
 jid within the signed payload, and possibly signing the challenge with the=
 source XID too. This would mean that the challenge was mutual, and mutuall=
y verifiable, though not end-to-end of course.<br><br>Four notes:<br><br>* =
I would strongly consider adding an expiry to the XID publication.<br>* I w=
ould also explicitly allow multiple XIDs - perhaps this is in place already=
, I didn&#39;t notice it (but haven&#39;t exhaustively searched).<br>* I wo=
uld also highly recommend examining PQ options (presumably KEM or HPKI base=
d) and also threshold cryptography might be interesting as well.<br>* By wa=
y of another approach worth examining, I&#39;d suggest looking at Philip Ha=
llam-Baker&#39;s Mesh and its id service, callsigns: <a href=3D"https://dat=
atracker.ietf.org/doc/html/draft-hallambaker-mesh-callsign-01">https://data=
tracker.ietf.org/doc/html/draft-hallambaker-mesh-callsign-01</a><div><div><=
br></div></div>Dave.</div></div>

--000000000000ca1c29065344411e--

--===============0649092129829515345==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]

--===============0649092129829515345==--