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. >
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
