Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS
On Fri, Dec 02, 2022 at 08:20:58PM +, Ollie wrote: > 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. DANE has 4 certificate usages, and 2 of them PKIX-TA(0) and PKIX-EE(1) are a combination of local trust-anchors (RFC 5280 PKIX) and DANE certificate constraints (server-side DNS CA or EE certificate or public key constraint). The security of PKIX-EE(1) is at least as strong as DANE-EE (self-signed), and already supports CT via the existing CAs. CT is already a centralised model, so your allergic reaction to public CAs while seeking mandatory CT is puzzling. Perhaps you can explain on ACME, or perhaps the (mostly inactive) d...@ietf.org list. With a PKIX-EE(1) server key "pin", no CA can unilaterally convince a DANE-enabled client that a misissued certificate is valid. If the client requires PKIX-EE(1) and does not support DANE-EE(3), then just compromising DNSSEC is also ineffective. Of course this is also the most operationally fragile model, offering two ways to have an outage. I don't see it gaining much popularity, but you can try to convince people otherwise. Good luck. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS
> 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 Sent: 02 December 2022 09:36 To: tls Subject: Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS On Fri, Dec 02, 2022 at 06:40:25AM +, 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 agen
Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS
On Fri, Dec 02, 2022 at 06:40:25AM +, 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
Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS
> 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.
> 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?
> In principle (I am not tracking whether there are extant
implementations), DANE-EE even supports TLS with RFC 7250 "raw public
> keys", where there are no certificate at all!
Huh, interesting - will look into, thanks.
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.
Consider the following use cases/user stories (U) and how (H) I believe
inclusion of SSCs to CT logs can support alongside CA certificates (CACs):
1.U: As a user agent, I want to prevent users from accessing potentially
malicious versions of a website so that I can protect users from harm.
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.
2.U: As a website operator, I want to monitor for certificates (intended to be
trusted by user agents) issued for my known domain so that I can look for any
misissuance to protect my end users against malicious versions.
2.H: Website operators could implement direct monitoring against a domain to
check the presented certificate (SSC or CAC) but what if a different network is
presenting something differently to other users - monitoring of CT logs that an
SSC has been issued (where as in 1. user agents require to not show
warning/block) could alert me to misissuance and that some of my users may
be/being targeted by some sort of (person-in-the-middle) attack where I can
look to mitigate/notify users.
3.U: As an organisation ("example.com") with many domains and websites, I want
to monitor for certificates issued against one of my brands so that I can
investigate and look for potentially malicious versions of my websites to
mitigate like creating takedown requests or adding to blocklists.
3.H: As with 2., direct monitoring could be done but that relies on me already
knowing about an asset or domain. If I could look for "*.example.*" or
"example.*" or "exampl3.*" in CT logs (either SSC or CAC) to identify domains I
didn't know about previously, I could investigate if they're a potentially
malicious version.
4.U: As a website operator, I want to check my certificates for imminent expiry
so that I can act on renewing or fixing the automated process before users are
presented with an error.
4.H: I could use a monitoring service that looks at CT logs where SSCs or CACs
are inventoried and checked for soon-to-be expired certificates, where I'd
receive a notification about them.
5.U: As an enterprise with many domains and websites, I want to monitor for
certificates issued against my domains so that I can investigate and look for
potential shadow IT to ensure compliance and increase efficiencies.
5.H: I could use a monitoring service to identify domains and ensure they're
part of my policies (e.g. must be in a CMDB or I only want SSCs or CACs to be
used).
Some additional thoughts:
- perhaps we could have "Expect-CT: 2" to designate a SSC vs current "1" for a
CAC for user agents to handle differently
- perhaps we could have a CAA flag for no CA but DANE:
example.com. IN CAA 0 issue "; tlsa=1"
Thanks,
Ollie___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS
> > I don't see this as different to the current spam potential with CT logs > right now - anyone could distribute out the creation of a bunch certificate > requests with the likes of Let's Encrypt and submit a bunch of certificate > chains to CT logs. Let's Encrypt (and other free CAs) have tight rate limits [1], which would be unreasonably tight for all applications. There is an escape hatch: if the rate limit is a problem, you can just buy a certificate with some other CA. Best, Bas [1] https://letsencrypt.org/docs/rate-limits/ > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS
On Wed, Nov 30, 2022 at 11:35:09PM +, Ollie wrote: > It increases the barrier of entry to someone having ownership of a > valid domain, configuring a full DNSSEC chain and configuring a valid > certificate with an appropriate DANE record. Everyone of those > trillion requests would need to be a real domain, with full DNSSEC and > signatures added to TLSA records. CTs could rate limit based on the > domain and/or common public keys from DNSSEC etc. 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? 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. In principle (I am not tracking whether there are extant implementations), DANE-EE even supports TLS with RFC 7250 "raw public keys", where there are no certificate at all! -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS
It increases the barrier of entry to someone having ownership of a valid domain, configuring a full DNSSEC chain and configuring a valid certificate with an appropriate DANE record. Everyone of those trillion requests would need to be a real domain, with full DNSSEC and signatures added to TLSA records. CTs could rate limit based on the domain and/or common public keys from DNSSEC etc. I don't see this as different to the current spam potential with CT logs right now - anyone could distribute out the creation of a bunch certificate requests with the likes of Let's Encrypt and submit a bunch of certificate chains to CT logs. I consider the current requirement to have a certificate chain rooted to a known CA to be synonymous with requiring a full DNSSEC chain, unless I'm missing (most likely!) something that CAs offer over DNS providers/registrars. Thanks, Ollie Original Message On 30 Nov 2022, 22:03, Bas Westerbaan wrote: > I don't see how your proposal prevents spam. With your proposal as is, > nothing stops me from adding trillions of self-signed certificates to the CT > logs. > > Best, > > Bas > > On Wed, Nov 30, 2022 at 8:55 PM Ollie wrote: > >> Hi Bas, >> >> Good question - my suggestion is for CT logs to check for the DANE records >> as explained in this git repo: https://github.com/OllieJC/justselfsigned.org >> Here's a copy: >> >> Unfortunately, existing CT logs do not support SSCs (self-signed >> certificates) due to spam concerns (rfc6962). The suggestion (being raised >> in rfc9162) is for CT logs to check for full DNSSEC compliance and TLSA >> records when generating a CT log entry for SSCs, which would work in the >> following way: >> >> 1. a new SSPC (Self-Signed Pre-Certificate) is generated with the following: >> - only valid domains >> - less than 90-day expiry (although this may start in the future) >> 2. the SSPC signature is added to tlsa._dane TLSA record for every domain >> 3. SSPC is submitted to a CT log >> 4. CT log checks for valid domains and associated TLSA signatures and issues >> an SCT (Signed Certificate Timestamp) >> 5. SSC (Self-Signed Certificates) is generated from the SSPC to include the >> SCT >> 6. SSC signature is added to TLSA records (likely replacing the >> pre-certificate signature) >> 7. SSC is submitted to the CT log >> 8. CT log checks for valid domains, associated TLSA records and a valid SCT >> >> Thanks, >> Ollie >> >> Original Message >> On 29 Nov 2022, 00:04, Bas Westerbaan < bas=40cloudflare@dmarc.ietf.org> >> wrote: >> In essence, I'm proposing that user agents should trust a fully DNSSEC domain with a TLS certificate set up using DANE, along with changes to CT log submission process to allow self-signed certificates (looking to suggest via rfc9162). >>> >>> How do you propose we prevent CT from being DoSed by a deluge of >>> self-signed certificates? >>> >>> Best, >>> >>> Bas___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS
I don't see how your proposal prevents spam. With your proposal as is, nothing stops me from adding trillions of self-signed certificates to the CT logs. Best, Bas On Wed, Nov 30, 2022 at 8:55 PM Ollie wrote: > Hi Bas, > > Good question - my suggestion is for CT logs to check for the DANE records > as explained in this git repo: > https://github.com/OllieJC/justselfsigned.org > Here's a copy: > > Unfortunately, existing CT logs do not support SSCs (self-signed > certificates) due to spam concerns (rfc6962). The suggestion (being raised > in rfc9162) is for CT logs to check for full DNSSEC compliance and TLSA > records when generating a CT log entry for SSCs, which would work in the > following way: > > 1. a new SSPC (Self-Signed Pre-Certificate) is generated with the > following: > - only valid domains > - less than 90-day expiry (although this may start in the future) > 2. the SSPC signature is added to tlsa._dane TLSA record for every domain > 3. SSPC is submitted to a CT log > 4. CT log checks for valid domains and associated TLSA signatures and > issues an SCT (Signed Certificate Timestamp) > 5. SSC (Self-Signed Certificates) is generated from the SSPC to include > the SCT > 6. SSC signature is added to TLSA records (likely replacing the > pre-certificate signature) > 7. SSC is submitted to the CT log > 8. CT log checks for valid domains, associated TLSA records and a valid SCT > > Thanks, > Ollie > > > Original Message > On 29 Nov 2022, 00:04, Bas Westerbaan < bas= > 40cloudflare@dmarc.ietf.org> wrote: > > > In essence, I'm proposing that user agents should trust a fully DNSSEC >> domain with a TLS certificate set up using DANE, along with changes to CT >> log submission process to allow self-signed certificates (looking to >> suggest via rfc9162). >> > > How do you propose we prevent CT from being DoSed by a deluge of > self-signed certificates? > > Best, > > Bas > > > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS
On Tue, Nov 29, 2022 at 04:04:58PM +0100, Bas Westerbaan wrote: > > On the other hand, the actual certificates are not what one > > would want to log anyway. Instead one would only want to log DS RRsets > > or NODATA proofs from eTLD registries (gTLDs, ccTLDs and also various > > 2LD, 3LD, ... suffixes operated by TLD registries). > > This is the case if you run your own authoritative DNS server. Most do not. > So you'd want transparency on the TLSA records as well. Your DNS operator is not some random 3rd party (like a public CA, with which you have no business relationship, and which can unilaterally issue certificates you never asked for). If you don't trust your DNS operator, use them only as a secondary, and run a hidden master where you do all the signing. Logging all TLSA RRsets (and denial thereof!) is impractical. The design does not have to perfect, it just has to be sufficiently useful and realisable. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS
Hi Bas, Good question - my suggestion is for CT logs to check for the DANE records as explained in this git repo: https://github.com/OllieJC/justselfsigned.org Here's a copy: Unfortunately, existing CT logs do not support SSCs (self-signed certificates) due to spam concerns (rfc6962). The suggestion (being raised in rfc9162) is for CT logs to check for full DNSSEC compliance and TLSA records when generating a CT log entry for SSCs, which would work in the following way: 1. a new SSPC (Self-Signed Pre-Certificate) is generated with the following: - only valid domains - less than 90-day expiry (although this may start in the future) 2. the SSPC signature is added to tlsa._dane TLSA record for every domain 3. SSPC is submitted to a CT log 4. CT log checks for valid domains and associated TLSA signatures and issues an SCT (Signed Certificate Timestamp) 5. SSC (Self-Signed Certificates) is generated from the SSPC to include the SCT 6. SSC signature is added to TLSA records (likely replacing the pre-certificate signature) 7. SSC is submitted to the CT log 8. CT log checks for valid domains, associated TLSA records and a valid SCT Thanks, Ollie Original Message On 29 Nov 2022, 00:04, Bas Westerbaan wrote: >> In essence, I'm proposing that user agents should trust a fully DNSSEC >> domain with a TLS certificate set up using DANE, along with changes to CT >> log submission process to allow self-signed certificates (looking to suggest >> via rfc9162). > > How do you propose we prevent CT from being DoSed by a deluge of self-signed > certificates? > > Best, > > Bas___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS
> > On the other hand, the actual certificates are not what one > would want to log anyway. Instead one would only want to log DS RRsets > or NODATA proofs from eTLD registries (gTLDs, ccTLDs and also various > 2LD, 3LD, ... suffixes operated by TLD registries). This is the case if you run your own authoritative DNS server. Most do not. So you'd want transparency on the TLSA records as well. Similar spamming would be possible by > obtaining certificates from many CAs and rolling them over as frequently > as possible. > CAs have quite strict rate-limits in place for free certificate issuance, so it's not a problem. Best, Bas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS
On Mon, Nov 28, 2022 at 06:23:36PM -0800, Eric Rescorla wrote:
> Thanks for the elaboration, Viktor.
>
> I think the TL;DR here is that this isn't TLS-relevant work at present.
> Either you get the certs directly or you get them via RFC 9102 but in
> either case, TLS has the appropriate support.
>
> If you don't need CT--I'm not entirely persuaded by Viktor's argument but I
> agree that the need is probably less than with WebPKI--then it seems like
> the technical work is done. If you do need CT, then probably your next stop
> is secdispatch, what with trans being closed.
Agreed, with the already mentioned clarification that the "CT" in
question would be DNSSEC-Transparency not X.509 CT, except when the DANE
usages are PKIX-{TA,EE} where the usual WebPKI rules also apply.
The "DNSSEC-Transparency" would log eTLD delegation security and any
delegations above that (root to TLD, TLD to 2LD eTLD public suffix,
...). The viability or a such a system has not been established, nor is
there even a sufficiently detailed potential design for evaluation.
It is not clear between wider DNSSEC adoption and availability of a CT
analogue which is the cart and which is the horse. I don't think that
lack such an analogue is presently a real obstacle to wider deployment
of DNSSEC. If I'm mistaken, perhaps this is something that could be
explored sooner.
--
Viktor.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS
Thanks for the elaboration, Viktor. I think the TL;DR here is that this isn't TLS-relevant work at present. Either you get the certs directly or you get them via RFC 9102 but in either case, TLS has the appropriate support. If you don't need CT--I'm not entirely persuaded by Viktor's argument but I agree that the need is probably less than with WebPKI--then it seems like the technical work is done. If you do need CT, then probably your next stop is secdispatch, what with trans being closed. -Ekr On Mon, Nov 28, 2022 at 5:32 PM Viktor Dukhovni wrote: > On Tue, Nov 29, 2022 at 01:04:14AM +0100, Bas Westerbaan wrote: > > > > In essence, I'm proposing that user agents should trust a fully DNSSEC > > > domain with a TLS certificate set up using DANE, along with changes to > CT > > > log submission process to allow self-signed certificates (looking to > > > suggest via rfc9162). > > > > How do you propose we prevent CT from being DoSed by a deluge of > > self-signed certificates? > > There isn't a known viable approach to combine the existing CT system > with DANE. On the other hand, the actual certificates are not what one > would want to log anyway. Instead one would only want to log DS RRsets > or NODATA proofs from eTLD registries (gTLDs, ccTLDs and also various > 2LD, 3LD, ... suffixes operated by TLD registries). Clients that > contribute to CT logs would need to run validating resolvers and > log signed delegations. > > Once a NODATA proof is recorded, no more such proofs are logged until > the delegation is again signed. > > So spamming can only happen as a result of repeated changes to a zones > DS RRset, including its deletion. Similar spamming would be possible by > obtaining certificates from many CAs and rolling them over as frequently > as possible. > > So long as a domain's DS RRset is not forged by the parent eTLD, what > (self-signed) certificates its TLSA records vouch for is an internal > matter, that is easily audited internally. Monitor your DNS, and don't > sign rogue TLSA records. > > -- > Viktor. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS
On Tue, Nov 29, 2022 at 01:04:14AM +0100, Bas Westerbaan wrote: > > In essence, I'm proposing that user agents should trust a fully DNSSEC > > domain with a TLS certificate set up using DANE, along with changes to CT > > log submission process to allow self-signed certificates (looking to > > suggest via rfc9162). > > How do you propose we prevent CT from being DoSed by a deluge of > self-signed certificates? There isn't a known viable approach to combine the existing CT system with DANE. On the other hand, the actual certificates are not what one would want to log anyway. Instead one would only want to log DS RRsets or NODATA proofs from eTLD registries (gTLDs, ccTLDs and also various 2LD, 3LD, ... suffixes operated by TLD registries). Clients that contribute to CT logs would need to run validating resolvers and log signed delegations. Once a NODATA proof is recorded, no more such proofs are logged until the delegation is again signed. So spamming can only happen as a result of repeated changes to a zones DS RRset, including its deletion. Similar spamming would be possible by obtaining certificates from many CAs and rolling them over as frequently as possible. So long as a domain's DS RRset is not forged by the parent eTLD, what (self-signed) certificates its TLSA records vouch for is an internal matter, that is easily audited internally. Monitor your DNS, and don't sign rogue TLSA records. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS
> > In essence, I'm proposing that user agents should trust a fully DNSSEC > domain with a TLS certificate set up using DANE, along with changes to CT > log submission process to allow self-signed certificates (looking to > suggest via rfc9162). > How do you propose we prevent CT from being DoSed by a deluge of self-signed certificates? Best, Bas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS
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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
