On Sat, Sep 28, 2024, 6:16 AM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> On Fri, Sep 27, 2024 at 11:55:52AM -0700, Watson Ladd wrote: > > > Spurred by recent IDs and events I've been thinking harder about how > > to get what we want out of TLS, DNS, and their interaction at the > > WebPKI. > > > > Fundamentally browsers can't rely on DNS to provide information about > > authentication because resolvers break that connection, and enforcing > > that means a lot of important things don't work. DNSSEC never gives > > the right signal (vanishes at resolver) so DANE doesn't really work, > > even if we could resolve extra records reliably. > > > > To my mind the registry should be able to issue X509 certs for second > > level domains/whoever controls a public suffix. After all, they know > > where you change DNS. Haven't sorted out how to deal with the level > > below that. Do others find this line of thought compelling? > > The premise is false. Resolvers don't hide any signals, they answer > whatever query the client sends. A client that does not interact with a > trustworthy local (think loopback) resolver, can do full DNSSEC > validation itself, by requesting all the requisite records from its > resolver (EDNS DO=1), and caching various DS/DNSKEY RRsets for > performance. > > The barrier isn't information loss, it is last-mile CPE impedance to any > DNS features that go beyond a minimal subset of RFC1035. > > Nothing is gained by registries becoming (name constrained) WebPKI CAs. > Indeed that works poorly, because in the RRR model, the registrant has > no authenticated channel to the registry to request certificate > issuance, the registry works exclusively with registrars, who would then > become trusted RAs, and then the number of trusted parties grows out of > control. > But if they can change who owns a domain there is currently no protection. Changing a domain gets you the ability to get a cert. > > The DNSSEC queries to locate and validate TLSA records can happen in > parallel with TLS session establishment, you only need the TLSA records > when validating the peer certificate, after resolving the A/AAAA records, > establishing the TCP connection and at least one RTT to receive the > server's CertificateVerify message. > > With DoH, a local resolver on the end device can receive all the > requisite data without impedance from broken DNS stacks on CPEs. > Browser vendors haven't seen the juice as worth the squeeze. It's also a model that sever operators need to adapt to vs. get the cert when adding the game to DNS. > > -- > Viktor. > > _______________________________________________ > Uta mailing list -- uta@ietf.org > To unsubscribe send an email to uta-le...@ietf.org >
_______________________________________________ Uta mailing list -- uta@ietf.org To unsubscribe send an email to uta-le...@ietf.org
