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 <me=40olliejc...@dmarc.ietf.org> 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
