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