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.
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.
--
Viktor.
_______________________________________________
Uta mailing list -- uta@ietf.org
To unsubscribe send an email to uta-le...@ietf.org
