Hi Dave, You sent this reply to me privately, and not to the list. I'm not sure if that was intentional? On Thu, 2024-08-15 at 12:38 +0100, Dave Cridland wrote: > Nick, > > If I understand correctly, you have essentially made the browser > vendor the trust anchor. This is also the current state of play - the > browser vendor ships the list of CAs, and is as such the trust > anchor. So really, you've just changed the mechanism. > > You have, furthermore, replaced ACME et al with an equivalent system > but moved it under the aegis of the browser vendor (directly, instead > of indirectly). I addressed this in another reply I just made. The browser vendor bootstraps a new browser so the browser can connect to and talk to the MIRROR NETWORK directly. Once the browser is connected to the MIRROR NETWORK, it gets a list of all MIRRORS from each of the MIRRORS it knows about. Future MIRROR LIST updates come from the MIRROR NETWORK, not the browser vendor. > I'm not entirely sure if your ACME replacement is as secure as ACME > itself, mind. I am open to critique from security minded experts, but would prefer details, not speculation. > Finally, I'm unconvinced that secure mirrors are economically viable > - I don't see the cost/benefit for the operator, especially when > comparing to the status quo. I imagine that SECURE MIRRORS would sit next to (or even be part of) DNS Servers. They would be located wherever DNS servers are found, and operated by the same people. I also think there should be a "TLSPolicy" TXT record, that works like DMARC and lets domain owners specify their preferred TLS policy. Among these options would be a "Required Secure Mirror" directive that requests the browser validate against a fifth data point- the domain owner's own SECURE MIRROR instance. The domain owner's SECURE MIRROR instance would sit on or with the domains owner's Authoritative DNS server, and validate directly against the master DNS records for that domain. Every organization would want to run their own instance for the added security of checking their own DNS records. > There are other bits of detail I fret about, such as your apparent > assertion that if a TLSA record is correct, then an A record must be. Again, I am open to critique from security-minded experts, but would prefer details, not speculation. > Vague counter-suggestion: TLSA records on a suffixed domain > controlled by the browser using DNSSEC keying shipped with the > browser. Then the validation in the background (and what sort of > TLSA records, if any, are returned) are entirely an implementation > choice by the browser vendor. Users could also use a different "trust > provider". Again, I've no clue what the economic imperative is here, > so I am merely floating vague ideas here. Much of this is what we are trying to avoid. No DNSSEC, no vendor lock in. And it's not economic. There's more to life than money.
