On Apr 5, 2018, at 2:43 AM, John Gilmore gnu@toad.com wrote:
Looks from this distance like the usual obstruction, i.e. "just give us a few more years of CA revenues, by delaying this standard further by demanding to add stuff that could easily have been added by a followup RFC".
I am confused, the folks most closely tied to the current browser/CA revenue model are proposing moving ahead with the crippled standard as-is, and those of us who want a standard that would be usable in browsers are asking for some changes, that should not cause much delay, but are needed to make the spec viable for browser HTTPS.
So you comment about a follow-up RFC and delay is perplexing. I certainly do not wish delay adoption in HTTPS I'm advocating for it, but that requires a small delay in publication to add two key missing features.
* Lack of denial of existence
* Lack of an extended TTL that commits the server to support the extension for the specified time (and provide either TLSA records or denial of existence of same or even DS records for the domain or some parent).
Without these, the protocol suffers trivial "stripping" downgrades. A server that implements DANE and supports the extension should be able to expect that clients will not ignore its absence and continue with legacy WebPKI. For if that's the case, the extension is pointless for the vast majority of applications (including browsers) where its adoption would need to be incremental. See the TLS WG discussion for details.