Re: Proposed XMPP Extension: XMPP Decentralized ID (XID)
Dave Cridland <[email protected]> Tue, 2 Jun 2026 13:30:51 +0100
| Newsgroups | gmane.network.jabber.standards-jig |
|---|---|
| Message-ID | <CAKHUCzymRh7XoCbuHsDgsd98C6_DRAwrbg+-QQz41THyEFTiJw@mail.gmail.com> |
--===============3223695418470406541== Content-Type: multipart/alternative; boundary="000000000000f1f2790653447b3a" --000000000000f1f2790653447b3a Content-Type: text/plain; charset="UTF-8" Goffi's response on Github, verbatim, with my response here (only): > > Hi @dwd thanks for your feedbacks (very valuable, as always). Thanks for the rapid response! > * I've chosen .internal because it's reserved for private application use ( > https://en.wikipedia.org/wiki/.internal, > https://www.rfc-editor.org/info/rfc6762/#appendix-G) actually to avoid > accidental reach of a real server. But you're right that on private > networks it can be an issue. Your xid.xmpp.org proposal can be a > solution. I would like to have more inputs on it before changing though. > My thinking is that if ".internal" is in use on private networks as a free-for-all, rather than having any global meaning. From RFC 6762, it's listed amongst "names which do not have meaning in the global context". The "proper" way of doing this would be to use a subdomain of a TLD like .arpa, or potentially make our own reserved one via the IETF like ".onion", though I seem to recall that would be hard. The only other solution I see is to use one the XSF controls. > * The use of JID syntax is to make XID trivially usable in many use cases > with little to no adaptation code (I'm thinking about "from"/"to" attribute > with serverless, but in general anywhere were a JID is expected, a XID > could be used). Please note the server mapping feature, and also in > business rules, the example of "publisher" attribute for pubsub. We have > also xmpp: URIs re-usable without any modification. > That makes sense, and is what I assumed. So some kind of domain is required. > * Your challenge comments are very relevant, I'll update after Council > vote if the spec is accepted. > I forgot, obviously, that it also needs a timestamp in the signed payload, to avoid replay. > * expiry would be nice indeed. Probably not mandatory though. > I wonder about this. The expiry can be updated frequently without rotating the key (and therefore XID), but it means that if a access to an account is lost, it will naturally "age out", and it also provides a simple mechanism to ensure challenges also expire predictably. > * Multiple XIDs are already explicitly allowed, as well as having the same > XID for various account on different domain names. > Right. I had missed that (as I anticipated). > * I'll have a look to what you suggest, but note that I try to make > something simple and easy to implement. The first byte is there to extend > algorithms easily later if necessary (for PQ or some other reason). One of > the advantages of Ed25519 is that it's already used with OMEMO, so most > clients already have an implementation. I had entirely missed the single byte (my error, I'm terrible at reading XML XEPs directly). I suggest that a single byte is insufficient. I'd pick either an HTTP/3-ish varint, or simply two octets. Just the numbers of PQ/hybrid KEMs coming out right now might get close to exhausting a single byte. > > I would like to avoid the discussion here if possible, and rather see it > on standard@ (more eyes, no need to chase feedbacks everywhere, and > archives are easier to retrieve). Agreed! Dave. On Tue, 2 Jun 2026 at 13:14, Dave Cridland <[email protected]> wrote: > 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. > --000000000000f1f2790653447b3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Goffi's response on Github, verbatim, with my response= here (only):<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi @dwd than= ks for your feedbacks (very valuable, as always).</blockquote><div><br></di= v><div>Thanks for the rapid response!</div><div>=C2=A0</div><blockquote cla= ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid = rgb(204,204,204);padding-left:1ex">* I've chosen .internal because it&#= 39;s reserved for private application use (<a href=3D"https://en.wikipedia.= org/wiki/.internal">https://en.wikipedia.org/wiki/.internal</a>, <a href=3D= "https://www.rfc-editor.org/info/rfc6762/#appendix-G">https://www.rfc-edito= r.org/info/rfc6762/#appendix-G</a>) actually to avoid accidental reach of a= real server. But you're right that on private networks it can be an is= sue. Your <a href=3D"http://xid.xmpp.org">xid.xmpp.org</a> proposal can be = a solution. I would like to have more inputs on it before changing though.<= br></blockquote><div><br></div><div>My thinking is that if ".internal&= quot; is in use on private networks as a free-for-all, rather than having a= ny global meaning. From RFC 6762, it's listed amongst "names which= do not have meaning in the global context".</div><div><br></div><div>= The "proper" way of doing this would be to use a subdomain of a T= LD like .arpa,=C2=A0or potentially make our own reserved one via the IETF l= ike ".onion", though I seem to recall that would be hard.</div><d= iv><br></div><div>The only other solution I see is to use one the XSF contr= ols.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi= n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex= ">* The use of JID syntax is to make XID trivially usable in many use cases= with little to no adaptation code (I'm thinking about "from"= /"to" attribute with serverless, but in general anywhere were a J= ID is expected, a XID could be used). Please note the server mapping featur= e, and also in business rules, the example of "publisher" attribu= te for pubsub. We have also xmpp: URIs re-usable without any modification.<= br></blockquote><div><br></div><div>That makes sense, and is what I assumed= . So some kind of domain is required.</div><div>=C2=A0</div><blockquote cla= ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid = rgb(204,204,204);padding-left:1ex">* Your challenge comments are very relev= ant, I'll update after Council vote if the spec is accepted.<br></block= quote><div><br></div><div>I forgot, obviously, that it also needs a timesta= mp in the signed payload, to avoid replay.</div><div>=C2=A0</div><blockquot= e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s= olid rgb(204,204,204);padding-left:1ex">* expiry would be nice indeed. Prob= ably not mandatory though.<br></blockquote><div><br></div><div>I wonder abo= ut this. The expiry can be updated frequently without rotating the key (and= therefore XID), but it means that if a access to an account is lost, it wi= ll naturally "age out", and it also provides a simple mechanism t= o ensure challenges also expire predictably.</div><div>=C2=A0</div><blockqu= ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px= solid rgb(204,204,204);padding-left:1ex">* Multiple XIDs are already expli= citly allowed, as well as having the same XID for various account on differ= ent domain names.<br></blockquote><div><br></div><div>Right. I had missed t= hat (as I anticipated).</div><div>=C2=A0</div><blockquote class=3D"gmail_qu= ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20= 4);padding-left:1ex">* I'll have a look to what you suggest, but note t= hat I try to make something simple and easy to implement. The first byte is= there to extend algorithms easily later if necessary (for PQ or some other= reason). One of the advantages of Ed25519 is that it's already used wi= th OMEMO, so most clients already have an implementation.</blockquote><div>= <br></div><div>I had entirely missed the single byte (my error, I'm ter= rible at reading XML XEPs directly).</div><div><br></div><div>I suggest tha= t a single byte is insufficient. I'd pick either an HTTP/3-ish varint, = or simply two octets. Just the numbers of PQ/hybrid KEMs coming out right n= ow might get close to exhausting a single byte.</div><div>=C2=A0</div><bloc= kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:= 1px solid rgb(204,204,204);padding-left:1ex"><br>I would like to avoid the = discussion here if possible, and rather see it on standard@ (more eyes, no = need to chase feedbacks everywhere, and archives are easier to retrieve).</= blockquote><div><br></div><div>Agreed!</div><div><br></div><div>Dave.=C2=A0= </div></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir= =3D"ltr" class=3D"gmail_attr">On Tue, 2 Jun 2026 at 13:14, Dave Cridland &l= t;<a href=3D"mailto:[email protected]">[email protected]</a>> wrote:<br>= </div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Re= peating my GH comment verbatim:<div><br>This generally looks good, and I su= pport publication.<br><br>Blockers for advancement:<br><br>* I don't th= ink 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 shar= e 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 t= hat the XSF creates a <a href=3D"http://xid.xmpp.org" target=3D"_blank">xid= .xmpp.org</a> domain for this purpose, with zero'd SRV records.<br>* Th= e 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.<br><br>Four notes:<br><br>* I= would strongly consider adding an expiry to the XID publication.<br>* I wo= uld also explicitly allow multiple XIDs - perhaps this is in place already,= I didn't notice it (but haven't exhaustively searched).<br>* I wou= ld also highly recommend examining PQ options (presumably KEM or HPKI based= ) and also threshold cryptography might be interesting as well.<br>* By way= of another approach worth examining, I'd suggest looking at Philip Hal= lam-Baker's Mesh and its id service, callsigns: <a href=3D"https://data= tracker.ietf.org/doc/html/draft-hallambaker-mesh-callsign-01" target=3D"_bl= ank">https://datatracker.ietf.org/doc/html/draft-hallambaker-mesh-callsign-= 01</a><div><div><br></div></div>Dave.</div></div> </blockquote></div> --000000000000f1f2790653447b3a-- --===============3223695418470406541== 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] --===============3223695418470406541==--