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

[Viktor Dukhovni <[e-mail]>]

On Fri, Dec 02, 2022 at 06:40:25AM +0000, Ollie wrote:
> > There's nothing to be gained by publishing SCTs in self-issued DANE-EE
> > validated certificates. Are you proposing to make SCTs mandatory in
> > DANE? Which user agents would insist on such SCTs and why? If not,
> > what problem would optionally including them solve?
> 
> Yes, primarily for browser user agents.  See below on use
> cases/problems.

In that case, why not just require the PKIX-EE and PKIX-TA usages, and
forgo "self-signed" certificates.  With PKIX-EE you still get to
explicitly identify a particular certificate in the TLSA records, but
it must now also follow all the WebPKI rules (including CT support if
applicable).

> > Note also that the "expiration" date of DANE-EE certificates is ignored,
> > the freshness of the key binding is attested via the TLSA record RRSIG,
> > rather than the dates in the certificate. The proposed 90-day limits on
> > "certificate lifetime" are antithetical to DANE-EE.
> 
> Noted and understood, although not sure I agree the certificate expiry
> should be ignored. What happens if I put a TLSA record for a CA
> certificate that then traditionally expires? Would user agents be
> expected to fall-back to using the RRSIG freshness?

A TLSA record for a "CA" certificate would be DANE-TA (usage 2) not
DANE-EE (usage 3), and in that case dates are not ignored in the issued
certificates.  Whether trust-anchors expire or not is not even explicit
in PKIX (a trust anchor is just a public key), and if the CA is matched
via its public key alone (say "TLSA 2 1 1 ...") then mutations of the
date are not covered by the TLSA record.

Again, and perhaps this should end this thread on the TLS WG list, where
it is not exactly on topic, it seems you're really looking for the
PKIX-TA(0) and PKIX-EE(1) certificate usages, and haven't analysed DANE
closely enough to see why those are already what you suggesting.

> I hadn't come across DNSSEC-Transparency so that probably covers a
> lot/all of the following, however I think it's worth considering CT
> log incorporation as that ecosystem is well established and the
> adoption of self-signed certificates (SSCs) would likely require
> little revision by monitors/user agents etc.

There is no DNSSEC transparency, it is just somewhat plausible
vapour-ware I've made up...

> 1.H: If presented with an SSC the user agent would require TLSA
> records and a complete DNSSEC chain and for the presence of an SCT for
> checking a CT log, doing those increases the level of assurance that
> the presented SSC is valid for the given website. If only one is
> valid, then some misissuance could have occured and a block or warning
> could be displayed to the user.

PKIX-EE with a certificate issued by a CA that participates in CT meet
your needs.  Along with browsers insisting on SCT (if that's what they
do when doing WebPKI).

Of course browser support for TLSA lookup does not look likely in the
mainstream browsers particularly soon.

If you can persuade your users to use a specialised browser with DANE
support (and I guess DoH or DoT required for DNS, else last mile
breakage is rather a barrier to DNSSEC), then perhaps you'd be able to
require PKIX-EE have your "self-signed" (really end-entity server-side
pinned) certificates.

Actually minting the certificates yourself vs. getting them from Let's
Encrypt hardly makes any difference with PKIX-EE, they're free either
way, and Let's Encrypt takes care of the CT side of things.

Sure LE doesn't presently check DNSSEC-signed TLSA records before
issuance.  But a DNSSEC-signed EE public key hash could well be a
supported ACME challenge type, that would in fact be stronger than the
current TOFU "proofs" of domain control.

So if there's an IETF group to nudge along the lines you suggest, it
might be ACME, rather than TLS, with a suitable directive in
DNSSEC-signed CAA records.  This could could be the only acceptable
domain control proof.  Solving also the problem of getting certificates
issued for various services that are not web servers.

    smtp.example.com. IN CAA ...
    smtp.example.com. IN CAA 128 spkialg=SHA2-256
    smtp.example.com. IN CAA 128 spkival=...

would require the CA to support the above critical attributes, and match
the spki value against against the requested public key.

-- 
    Viktor.