[dane] [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension (fwd)

[Viktor Dukhovni]

> On Apr 5, 2018, at 2:43 AM, John Gilmore <gnu at 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.

-- 
	Viktor.