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

Reply via email to