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 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
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
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
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
