Kind Regards,
Pawel On 20.03.25 19:53, Petr Špaček wrote:
On 3/7/25 19:02, Phillip Hallam-Baker wrote:On Thu, Mar 6, 2025 at 6:16 PM Ted Lemon <mel...@fugue.com <mailto:mel...@fugue.com>> wrote:__ 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.I believe that the core problem is usability. If we can convince router providers that we have solved the usability issues, we are much more likely to expect stuff we produce to be used and that is going to make it much easier to get them to implement.Every step we ask of consumers reduces the number of likely users by at least 50% and some say 90%.Turning configurations into QR codes might seem trivial and unnecessary to DNSOPS folk but it is really important when it comes to making things 'just work'.One option we might look at is companies like Ubiquiti which have been producing gear that rise above the 1990s tech most in that market seem to consider acceptable. But that is not my immediate concern. Let's start off with the problem of how to get a public DNS provider onboard.What if there was a way that Alice could package up an Ed25519 or Ed448 key into a URI and that was the only thing she needed to pass to her DNS authoritative server for them to set up the zone so her applications can push the updates out to it?Shipping a key is not a _technical_ problem. E.g. you can wrap a public key into KEY RR represented as DUJ. That KEY RR is then used to authenticate SIG(0) UPDATEs. KEY RR + SIG(0) works for many years now.Much harder problem is how to attach authorization data to a given key. To what zone does the key apply? To what RR types? Does the server care if RRs were added by someone else/Is there a concept of 'ownership' of a RR? Or all users/keys equal? etc. etc.Authentication can be solved with some technical effort. For authorization, I'm not so sure because requirements differ wildly depending on use-case.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
