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
[email protected]
https://www.ietf.org/mailman/listinfo/tls
