Stripping of TLS generally is solved, so why would stripping of the extension in particular be a problem? The same kinds of solution work for both. TLS covers the extension list in the handshake hash, so what's the attack here?
An attacker with a compromised certificate MITMs the site, terminates and proxies TLS using the bad certificate, and the TLS UA never sees that it's supposed to enforce DANE too?
That's what ExtSupportLifetime is for. Other pinning approaches, e.g. HSTS-like preload lists, work too. Union them. You need only one of N mechanisms to say "my domain promises to staple DNSSEC" to make the browser expect it and fail hard if it's not there. But stapling is just a transitional measure anyway.
The better solution, of course, is to just fix DNSSEC so the problem doesn't occur in the first place. There's no need to staple and no opportunity to strip if you can verify the DNS resolution end to end.
So, in this "doesn't work" scenario, it just so happens that the very first client contact endpoint is via this MITM, and the certificate is compromised at this moment, and HSTS or something prevents stripping TLS entirely, and the endpoint isn't on a DANE preload list (although it is on the HSTS one!) and DNSSEC isn't working in the client's environment? All at once?
Yeah, right.
Who's going to use HSTS, and DANE, but not set the "I'm using DANE" bit in the HSTS config? And if you're not using HSTS, an attacker can just strip TLS anyway and you lose regardless.
So yeah, it does work, and the "doesn't work" failure mode is server misconfiguration.
An attacker with a compromised certificate MITMs the site, terminates and proxies TLS using the bad certificate, and the TLS UA never sees that it's supposed to enforce DANE too?
That's what ExtSupportLifetime is for. Other pinning approaches, e.g. HSTS-like preload lists, work too. Union them. You need only one of N mechanisms to say "my domain promises to staple DNSSEC" to make the browser expect it and fail hard if it's not there. But stapling is just a transitional measure anyway.
The better solution, of course, is to just fix DNSSEC so the problem doesn't occur in the first place. There's no need to staple and no opportunity to strip if you can verify the DNS resolution end to end.
So, in this "doesn't work" scenario, it just so happens that the very first client contact endpoint is via this MITM, and the certificate is compromised at this moment, and HSTS or something prevents stripping TLS entirely, and the endpoint isn't on a DANE preload list (although it is on the HSTS one!) and DNSSEC isn't working in the client's environment? All at once?
Yeah, right.
Who's going to use HSTS, and DANE, but not set the "I'm using DANE" bit in the HSTS config? And if you're not using HSTS, an attacker can just strip TLS anyway and you lose regardless.
So yeah, it does work, and the "doesn't work" failure mode is server misconfiguration.