And is in fact used in IoT via the SRP protocol. Eg CSA/Matter and Thread use it for updating the local dns zone.
On Wed, Mar 5, 2025, at 10:11 PM, Mark Andrews wrote: > You do know that SIG(0) has existed for 20 years to authenticate UPDATE > requests? > > > -- > Mark Andrews > >> On 6 Mar 2025, at 07:08, Phillip Hallam-Baker <ph...@hallambaker.com> wrote: >> >> Coming late to this, sorry. >> >> I am looking for a mechanism that allows a user to easily attach IoT devices >> to a DNS persona that is assigned to them. This is an extension of my work >> on DNS handles. >> >> So I am very interested in a better means of updating DNS records than TSIG >> because symmetric keys are yucky. The reviews on the alternatives like GSS >> seem to dislike those as well. >> >> Seems to me that this is something we should be looking at as more than just >> a patch job. The existing methods are really limited, we really need a >> public key based authentication scheme to do the job properly. Any new >> mechanism is going to have to be at least capable of PQC secure interaction. >> >> The current draft seems to sit in a nomans-land between being a DNS >> configuration tool and a device/service configuration tool. There is a good >> case for both but I don't see a good case for DNS configuration tool-lite. >> >> What I have written in response to the SETTLE proposal is an 'all-in-one' >> tool that performs the DNS configuration (via UPDATE) and WebPKI >> configuration (via ACME). That does the job but it is something that really >> has to be professionally configured to do the DNS integration. >> >> >> Some of the technology I have developed already might be relevant. >> >> Blue Sky is basically an OpenID type infrastructure that uses DNS names as >> the user identifier. These are linked to a permanent user identifier by >> means of a prefixed TXT record. My handle definition for >> @phill.hallambaker.com is: >> >> _atproto.phill.hallambaker.com. IN TXT "did=did:plc:k647x4n6h3jm347u3t5cm6ki" >> >> The ATprotocol user is essentially 120% of OpenID functionality with about >> 10% of the code. It is not an 'identity framework', it is a fully worked >> solution. >> >> So the obvious next step is to extend it to support end-to-end secure >> communication: >> >> _jscontact.phill.hallambaker.com. IN TXT >> "uri=jscontact://mplace2.social/egnb-zk3g-bm4d-qipg-64jh-doxk-7rvq" >> >> You can see that record unpacked here: >> >> https://mplace2.social/Visitor/phill.hallambaker.com >> >> As you can see, my OpenPGP, S/MIME, Signal and Git contact addresses and >> credentials are all there. So if you resolve my DNS handle, you can do >> end-to-end secure chat with me via any protocol I list in my contact, legacy >> or new on a TOFU basis. If you scan the QR code on my business card, you get >> end-to-end trust from the start. >> >> The form of the URI is very particular: >> >> * "egnb-zk3g-bm4d-qipg-64jh-doxk-7rvq" is the truncated SHA-3-512 digest of >> the contact plaintext >> >> * The aes-gcm-256 encrypted contact is retrieved from a well-known service >> at mplace2.social using >> SHAKE256("locator:egnb-zk3g-bm4d-qipg-64jh-doxk-7rvq") as the path >> >> * The encrypted contact is decrypted using >> SHAKE256("locator:egnb-zk3g-bm4d-qipg-64jh-doxk-7rvq") to obtain the key and >> IV. >> >> * The recovered plaintext MUST be checked against the digest value. >> >> The key can be expressed at any precision up to 256 bits to achieve the >> desired work factor. >> >> So having given users the ability to create global personas labelled by a >> DNS name, seems that we should complete the deal and allow Alice to set up a >> persona for her home and provision devices to it giving them the ability to >> do HTTPS with regular Web browsers. >> >> So Alice sets up 'alicehome.cryptomesh.org', she adds herself, >> (@alice.cryptomesh.org), Bob (@bob.example.com) and Carol >> (@carol.example.net) to the authorized users list. >> >> Alice can now buy a camera, scan a QR code on it plug it in and immediately >> start using it as https://camera1.alicehome.cryptomesh.org/. The camera has >> a device description on it that gives 'camera' as the default name. It gets >> a free ACME certificate and uses the OAUTH specifications attached to their >> handles to authenticate Alice, Bob and Carol. >> >> >> My current TSIG scheme works but requires a shared secret that makes things >> really a bit nasty. >> >> So let's start with the notion of using the uri mechanism to bind a public >> key into a zone file. This means we can now use keys of any length - >> RSA4096, ML-DSA-87, ML-KEM-1024 all are fine. We could probably pack this >> into a SIG record. >> >> Anyone interested in a side meeting to hammer this out? The other related >> forcing function is going to be PQC DNSSEC and that is likely to mean >> changes as well. >> >> >> >> _______________________________________________ >> DNSOP mailing list -- dnsop@ietf.org >> To unsubscribe send an email to dnsop-le...@ietf.org > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
