Re: [webkit-dev] Interest in supporting cryptographically-generated domain names?
Hi Demi, Interesting idea! Comments in-line:
On May 4, 2025, at 5:52 PM, Demi Marie Obenour via webkit-dev <webkit-dev@lists.webkit.org> wrote:
A major limitation of the Web PKI is that it cannot issue certificates for devices that do not own a public domain name or IP address. To solve this problem, I have created a proposal for incorporating a public key in the domain name itself, allowing a server to be authenticated without involving a third party. The proposal can be found at <https://demimarie.github.io/cryptographically-generated-domains.html>.
This idea of using the hash of a public has never gained widespread excitement, but maybe this time is different! The proposal seems to combine some previous ideas around self-authenticating addresses [0] and self-authenticating traditional addresses [1]. I recommend citing the prior work in the proposal for completeness. The Open Questions section mentions Tor’s onion services, and indeed a lot can be learned from them with regard to their addressing scheme. Primarily, cryptographic hashes are not user-friendly, in fact some would consider them user-hostile because they lack any inherent meaning and require byte-for-byte comparison that is tedious. However, the value of 1) uniqueness, 2) self-authentication, and 3) end-to-end security are important characteristics.
Is an implementation of this something that Chromium would be interested in? I do plan to propose this to the IETF, but first I want to check if there is interest from browser vendors.
I assume you forgot to replace Chromium with WebKit? :) But, with regard to Chromium, I believe they were exploring usability improvements in the area of supporting top-level HTTPS navigations to devices on a local network that don’t have globally valid TLS certificates. I can’t find the proposal at the moment, though. I also recommend citing RFC 7686 [3] and CAB ballot 201 [4]. I am interested in seeing if there is broader support of this idea, too. [0] https://spec.torproject.org/rend-spec/encoding-onion-addresses.html [1] https://www.researchgate.net/publication/337510353_Self-Authenticating_Tradi... [3] https://www.rfc-editor.org/rfc/rfc7686.html [4] https://cabforum.org/2017/06/08/ballot-201-.onion-revisions/
On 5/5/25 10:44, Matthew Finkel wrote:
Hi Demi,
Interesting idea! Comments in-line:
On May 4, 2025, at 5:52 PM, Demi Marie Obenour via webkit-dev <webkit-dev@lists.webkit.org> wrote:
A major limitation of the Web PKI is that it cannot issue certificates for devices that do not own a public domain name or IP address. To solve this problem, I have created a proposal for incorporating a public key in the domain name itself, allowing a server to be authenticated without involving a third party. The proposal can be found at <https://demimarie.github.io/cryptographically-generated-domains.html>.
This idea of using the hash of a public has never gained widespread excitement, but maybe this time is different! The proposal seems to combine some previous ideas around self-authenticating addresses [0] and self-authenticating traditional addresses [1]. I recommend citing the prior work in the proposal for completeness. The Open Questions section mentions Tor’s onion services, and indeed a lot can be learned from them with regard to their addressing scheme. Primarily, cryptographic hashes are not user-friendly, in fact some would consider them user-hostile because they lack any inherent meaning and require byte-for-byte comparison that is tedious. However, the value of 1) uniqueness, 2) self-authentication, and 3) end-to-end security are important characteristics.
The main difference here is that, at least initially, this is mainly intended for IoT devices, where the link is provided via QR code. This avoids the user ever having to memorize the domain name. The user could be prompted to save the domain name under a human-readable alias for future use.
Is an implementation of this something that Chromium would be interested in? I do plan to propose this to the IETF, but first I want to check if there is interest from browser vendors.
I assume you forgot to replace Chromium with WebKit? :) But, with regard to Chromium, I believe they were exploring usability improvements in the area of supporting top-level HTTPS navigations to devices on a local network that don’t have globally valid TLS certificates. I can’t find the proposal at the moment, though.
I also recommend citing RFC 7686 [3] and CAB ballot 201 [4].
I updated the article with RFC 7686. I left out CAB ballot 201 because I didn't see it being relevant. I also added your name in the credits.
I am interested in seeing if there is broader support of this idea, too.
[0] https://spec.torproject.org/rend-spec/encoding-onion-addresses.html [1] https://www.researchgate.net/publication/337510353_Self-Authenticating_Tradi... [3] https://www.rfc-editor.org/rfc/rfc7686.html [4] https://cabforum.org/2017/06/08/ballot-201-.onion-revisions/
What would the logical next step be? Should I try to implement this in libsoup (used by WebKitGTK), or should I create an Internet Draft? -- Sincerely, Demi Marie Obenour (she/her/hers)
participants (2)
-
Demi Marie Obenour
-
Matthew Finkel