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 <ietf-d...@dukhovni.org> 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
