Remember when Chrome developers claimed they'd remove static pinning for their own domains after dropping HPKP support? The only real change was disallowing others from using static pinning.
They've also continued to sabotage DNSSEC+DANE despite WebPKI depending on DNS security.
Conversation
Google clearly doesn't believe an entirely reactive mechanism (Certificate Transparency) makes pinning unnecessary. They aren't eating their own dog food despite promising to do it.
There are a clearly a lot of people at Google who do think DNSSEC is important but not at Chrome.
1
3
15
Google Domains uses DNSSEC by default and there are alternate Google SMTP domains with DNSSEC available for domains using G Suite.
mx1.smtp.goog
mx2.smtp.goog
mx3.smtp.goog
mx4.smtp.goog
broadcom.com uses these, among others.
1
1
13
They could easily add TLSA records for those and have proper authenticated encryption instead of the weak security offered by MTA-STS.
MTA-STS is WebPKI sans CT with insecure connections by default and no equivalent to HSTS preloading. Not even easier than DANE. It's harder...
1
4
15
HTTPS security for the web is based on trusting DNS and also thousands of additional parties able to issue valid certificates for any domain.
They're trusted to validate domain control, but without any real authentication since DNSSEC is just a recommendation not a requirement.
2
2
14
Choice is not between trusting DNS or WebPKI but rather whether you trust both DNS and WebPKI or just DNS via DANE.
DANE can be introduced alongside the existing system and CT can still be required.
When DoT or DoH are in use, middlebox compatibility with DNSSEC is irrelevant.