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
