Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Viktor Dukhovni <[e-mail]>]

> On Apr 4, 2018, at 1:50 PM, Joseph Salowey <[e-mail]> wrote:
> 
> 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

The discussion so far has demonstrated the need for an important clarification about the nature of the pinning in B):

  * The pin would not require *anything* more than continuing support for the extension.
  * In particular, it would not require continued presence of TLSA records, nor even
    continued DNSSEC support by the server's domain.
  * This is because the server can respond with denial of existence of either its TLSA
    records, or even of the the DS records for its domain or some parent domain.

This is why my claim that this is essentially like STS, and nothing like HPKP is valid.

A corollary of the above is that (B) requires (A).  Just (B) alone is not sufficient,
it is too limited a mechanism without denial of existence.

If support for the extension itself is mandatory in some application context (implicit
unbounded pin), then of course (A) alone is enough, but we should note that such implicit
indefinite pinning is fragile during partial deployment and does not protect applications
where the implicit requirement is not an option (incremental deployment).

Therefore, the real choice before us is (C) or not (C), the choices of (A) alone or (B)
alone are unsound half-measures.

(C) is essentially STS for dane chains over TLS with downgrade protection after first
contact, and imposes no burden on the present implementors.  If they were willing to
implement without a pin or denial of existence, they can ignore the pin TTL and never
transmit denial of existence (which their clients would not expect to process).

On the other hand, they may find after some experience that the proposed features
are actually useful, and might add them to their application logic.  I don't know
whether DANE is mandatory with DPRIV or is just an "additive" alternative to WebPKI.
If the latter, with the present draft it is trivially stripped, and again there is
little incentive to not just use WebPKI, especially if DANE support is not required
from all clients (thus servers need at least WebPKI).

Looking at RFC8310, I see hints of support for both WebPKI and DANE, with no guidance
as to how a client is to choose between them, accept either both, avoid downgrades
to one when the other is preferred, ...

So I rather suspect that even the DPRIV use-case, which supposedly does not need
the proposed changes, actually does need them for meaningful security from using
DANE, and we've not just not looked at the details closely enough yet.  It may
well turn out not substantially different from the browser use-case that is not
adequately met by the current draft.

Can someone explain briefly how DPRIV avoids the same downgrade issues, and
negative adoption incentives (cost-benfit comparison)?  If it turns out that
no adequate explanation is possible, and indeed the same issues are present,
then the proposed changes (which are still needed elsewhere) are all the
more pressing.

-- 
	Viktor.