I did a proof of concept at a hackathon about four years ago, but getting stuff like this into actual routers is hard. We are working on it in CSA/Matter, but I don’t see that happening this year.
On Thu, Mar 6, 2025, at 5:44 PM, Phillip Hallam-Baker wrote: > How widespread is the support for DNS Update of any kind in the DNS servers > built into Home Routers? > > The discussion in SETTLE appears to be currently premised on the answer being > 'almost nowhere'. If the answer is 'pretty substantial, things become a lot > easier... > > On Thu, Mar 6, 2025 at 9:57 AM Ted Lemon <mel...@fugue.com> wrote: >> __ >> 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
