> 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'm happy to end the thread here and apologies it is not on topic for the TLS WG, I'm not familiar with the WG/mailing lists so I was mainly looking for guidance. That said, in reply to your points, I understand DANE to a level that I know PKIX isn't applicable to my original intention/query, so perhaps I haven't been clear with what I'm looking to achieve. I want all mainstream browsers (like Chrome, Edge, Firefox etc.) to trust self-signed certificates to remove the reliance on CAs and allow website operators to have the option to move away from PKI (concerns around centralisation/points-of-failure) while still supporting monitoring via CT logs etc. > There is no DNSSEC transparency, it is just somewhat plausible > vapour-ware I've made up... I found this after your mention: https://datatracker.ietf.org/doc/html/draft-zhang-trans-ct-dnssec-03 > Of course browser support for TLSA lookup does not look likely in the > mainstream browsers particularly soon. Right. That's what I'm advocating for. > 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. I don't want _my_ users to have to do anything. I want _all_ users to be able to trust self-signed certificates with mainstream browsers. > 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. Cost isn't a concern, reliance on a CA is. So getting certificates from LE is a big difference. > 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. Thanks, I'll raise there. When I first looked at the groups I had the impression it was closed but I can now see the mailing list is active. Ollie -----Original Message----- From: Viktor Dukhovni <ietf-d...@dukhovni.org> Sent: 02 December 2022 09:36 To: tls <tls@ietf.org> Subject: Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
