Subject: Re: [dane] [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension [AT LEAST (A)]

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 Apr 2018 14:32:10 -0400

> On Apr 4, 2018, at 1:50 PM, Joseph Salowey <[email-masked]> wrote:
> 
> If the answer to 1) is no then please indicate if you think the working group should work on the document to include 
> 
> A) Recommendation of adding denial of existence proofs in the chain provided by the extension
> B) Adding signaling to require the use of this extension for a period of time (Pinning with TTL)
> C) Both

While I am a vocal supporter of (C), I'd like to take a moment to explain why AT LEAST (A)
is needed.

  * The present text requires (Section 3.4) that the server's response
    present a validated TLSA RRset:

	   The first RRset in the chain MUST contain the TLSA record set
           being presented

  * The present text (Section 8) says:

	   Green field applications that are designed to always employ this
           extension, could of course unconditionally mandate its use.

Therefore such "green field" applications (presumably some of the ones
ready to implement now) effectively mandate DNSSEC and TLSA records
at the server, NOT JUST support for the extension.

This needlessly limits the usability of such applications.  The
server domain cannot continue to support the extension and
interoperate with the client if it at some points decides to
stop publishing TLSA records or perhaps even stop using DNSSEC.

It makes a lot more sense for servers to be able to continue to
support the extension, but respond with denial of existence when
when the have no TLSA records or the zone is unsigned (no DS
RRs at some ancestor).  That way a server can communicate its
change of status to a client, which may *then* be willing to
accept alternative authentication (WebPKI, for example).

Option (A) does not change the wire formats, it just relaxes
the requirement to provide TLSA records, and would allow or
encourage the server to return whatever is the truth about
its TLSA records (presense, absence or unsigned zone).  The
client can then act accordingly.

Just (A) would of course still many clients in the dark about
when it might be safe to "mandate" the extension for particular
domains, and I'd be sad about that (if anyone cares :-), but it
is important to realize that not doing (A) is a significant
omission.

I'd like to encourage the authors and WG to amend the draft to
relax section 3.4 to allow (and encourage when applicable)
denial of existence replies.  This would better serve the
"green field" applications that would like to avail themselves
of this extension and require it of all servers, whether they
have DNSSEC and TLSA records or not.

-- 
	Viktor.

---

From: John Gilmore <[email-masked]>
Date: Thu, 12 Apr 2018 11:44:52 -0700

> at the server, NOT JUST support for the extension.

Viktor, I believe you have confused a "could" with a "mandate".

The text of this RFC does not require future green field applications
to mandate the use of this exension.  It merely allows them to do so.
None need ever do so.  If any ever did, the future RFC could specify
how servers which do not have validated TLSA records should handle the
situation.  Different future protocols might choose different ways
to handle this (e.g. don't send the extension at all; or send a validated
denial; or send some kind of flag saying that the server doesn't even have
a validated denial because it isn't using DNS or because some domain on
its path to the DNS root isn't doing DNSSEC or isn't using NSECx records).

Please, let this RFC go, rather than requiring that this committee
first insert into it a paper spec for what some future protocol should
do, without even knowing what the future protocol is.

	John

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 Apr 2018 15:05:09 -0400

> On Apr 12, 2018, at 2:44 PM, John Gilmore <[email-masked]> wrote:
> 

As to this point, I'm not now and have never been confused about
that.  The present draft, as explained upthread, perhaps in too
many ways and in too many words, offers no value to applications
that don't mandate the use of the extension, if the application
also excepts WebPKI, and the extension is optional, then a
cost/benefit analysis shows that use of the DANE extension offers
only complexity and no security benefit.  Opportunistic use-cases
of the present draft won't get deployed, they make no sense.

-- 
	Viktor.