> On Apr 4, 2018, at 1:50 PM, Joseph Salowey <j...@salowey.net> 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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
