Conversation

This Tweet was deleted by the Tweet author. Learn more

Replying to

Please don't let them impose inane policies on what sort of DANE records are acceptable for web. Anything should be accepted and completely override webpki if DANE semantics say it does (DANE-EE(3) or -TA(2) vs PKIX-*(0 or 1)).

Replying to

and

No. DANE-TA and DANE-TE allow TLD operators (and thus anyone who can force them through shady court orders) to completely circumvent TLS without even leaving a trace. PKIX-TA and PKIX-EE would at least force them to leave a trace within the certificate transparency logs.

Replying to

and

This threat is overstated to the point of being standard anti-DNSSEC FUD, but indeed we do need a DNSSEC analogue of CT. Unlike with webpki CT, it doesn't require trusting CAs to adhere to policy to create such a thing; it can be constructed from observation.

Replying to

and

No, IMO it cannot. Split horizon configurations are a standard feature in most namesevers. DNSSEC is an important addition to DNS security, but it's no silver bullet.

Replying to

and

Anyone who's seen the forged DS has cryptographic proof of its existence. Just need to gamify publication of it.

Replying to

and

You'd still be able to circumvent that through split horizon DNS. IMO there needs to be a way to enforce that all DS records and proofs of non-existence of DS records at the TLD level be signed by and committed to trustworthy public append-only logs.

Replying to

and

I don't follow what you're saying you'd be circumventing. The idea is that someone, somewhere sees the forged DS and submits it to an append-only log because doing so is well inventivized. And if you see one nobody else is submitting yet, it's likely forged.

Replying to

and

However with increased use of centralized DoH services, there is no split horizon (at root/tld level). Cloudflare sees everything and shows the same DS to everyone.

Replying to

and

In theory, there could be Certificate Transparency logs simply accepting self-signed certificates. The issue would be convincing a bunch of organizations to run those kinds of logs and coming up with mitigations to deal with spam that would usually be offloaded to the CAs.

Replying to

and

Let's Encrypt issues an enormous number of certificates so it places a huge load on the logs they use. It needs to be very reliable, high availability infrastructure. More diversity of logs would be really nice. If it's harder to host, there isn't as much diversity of logs.

6:30 AM · Jan 5, 2021Twitter Web App