Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

[Viktor Dukhovni <[e-mail]>]

On Mon, Nov 28, 2022 at 12:27:07PM -0800, Eric Rescorla wrote:

> How much of the TLS part of this objective is achieved by RFC 9102?

Well, RFC9102 is at a different layer.  It provides a mechanism for
clients to obtain a TLSA RRset by other means than direct DNS lookup,
because that often runs into last mile barriers (as you reported at
IETF114 IIRC, is there now a paper you can link to?).

Once the client has TLSA records be it directly from DNS, or
server-facilitated via a TLS extension, at that point what's trusted
should not depend materially on how the TLSA records were obtained.

So back to the OP's question, what appears to be missing here?  It seems
to me that "3 1 1" TLSA records are sufficient to allow self-signed
certificates to validate, indeed this is already quite common in TLS for
SMTP.  The only known nit is that for an HTTP browser one needs to heed
a potential UKS issue, and so the advice in RFC7671 to ignore the
hostname in certificates validated via a TLSA "3 1 1" record is not
appropriate for "https" in browsers that support following remotely
supplied links, redirects, care about cross-origin issues, ...

In simpler protocols that just move data between a client and server,
the RFC7671 semantics for "3 1 1" records reduce the potential for
operator error (seen with low, but non-zero frequency for "2 1 1"
records, where some MX hosts now and then sport certificates that don't
match their names).

-- 
    Viktor.