Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps

[Benjamin Kaduk <[e-mail]>]

On Tue, Oct 16, 2018 at 06:16:22PM -0400, Daniel Kahn Gillmor wrote:
> 
> I agree with both Tom and Viktor that the current draft seems to be
> misaligned between the goals and the stated scope.

I also agree that there is some misalignment of this nature.

My attempt at a root cause analysis would be that the current text in
the Introduction is essentially saying "let clients in bad networks do
DANE", but "doing DANE" is a fairly nebulous thing, and if different
people are focusing on "doing DANE" in different ways, we can get into
conflict about whether a specific proposed mechanism advances our
particular goals.


So what is "doing DANE", then?  In the course of the on-list, off-list,
side meeting and interim discussions, I've benefited greatly from
hearing from a lot of experts, and I deeply appreciate the patience and
persistence that the participants thereof have shown in working to
advance a document in this space.  It was not always easy, but I think
we are making progress.

In the context of this discussion, I propose that DANE is a way to allow
a TLS server operator[1] to indicate to a TLS client information about
how the server would like to be authenticated.  The practical effect of
this new source of information depends on what the client would be doing
*without* the DANE information, though, since we have this large
deployed base that is currently not doing DANE but could do DANE in the
future.  If we want to analyze the (security and other) properties of
adding DANE, we must consider both the starting point and the end state.

I suggest that if we limit the stated scope from an open-ended "doing
DANE" to also state which cases of "doing DANE" we have analyzed
(leaving open the possibility for future analysis to confirm the
mechanisms we define as usable in other cases), then we can get a clear
answer on whether the proposed mechanism meets the requirements of each
listed case, without introducing negative externalities for either the
protocol participants or the Internet as a whole.  This is not to
exclude the "greenfield" case, of course -- a list of cases to consider
might include things like:

- client does not currently exist, and insists on receiving DANE records
  via TLS extension; server wants to use TLSA with PKIX-{TA,EE}

- client does not currently exist, and insists on receiving DANE records
  via TLS extension; server wants to use TLSA with DANE-{TA,EE}

- client currently accepts "Web PKI" certificates but is willing to do
  DANE; server wants to use TLSA with PKIX-{TA,EE}

- client currently accepts "Web PKI" certificates but is willing to do
  DANE; server wants to use TLSA with DANE-{TA,EE}

- client currently will opportunistically accept any certificate but is
  willing to apply DANE restrictions; server wants to use TLSA with
  DANE-{TA,EE}

- client currently will opportunistically accept any certificate but is
  willing to apply DANE restrictions; server wants to use TLSA with
  PKIX-{TA,EE}

where I separate out the DANE- and PKIX- usage values since they may
require a separate security analysis.  (If they don't; great, we can
consolidate them in the document.)

I don't think we would necessarily need to come to consensus on which of
these cases are "most important", so long as we can provide a mechanism
that will satisfy the requirements of all cases that we want to list in
the document.

> I wanted the draft to be done by now because i think it will be useful
> in "greenfield" scenarios -- ones where the use case itself can mandate
> the extension without negotiation, but i understand Viktor's point that
> without any sort of negotiated pinning mechanism, the draft is probably
> not useful for non-greenfield scenarios (without pinning the existence
> of the extension, it cannot reduce the attack surface represented by the
> CAs, and instead only represents an additional vector of attack).

Right -- if the client is currently willing to do Web PKI (or worse), an
attacker that can get a bogus Web PKI (or self-signed) certificate could
keep the client ignorant of the true server's preference and get the
client to errenously complete a handshake.  We would like a way to
deprive the attacker of such a capability, though in at least some
situations we cannot do so with 100% reliability.  We could perhaps have
a success criteria for this TLS extension (as a security mechanism),
that it both:

(1) provides a channel for DANE records that is reliable in the absence of
    an attack

and

(2) reduces the ability of an attacker to cause the client to ignore the
    server's authentication preference

I think that just meeting the above two conditions could provide enough
value to merit publishing, even without attempting to add something
like:

(3) allows the client to realistically hard-fail connections where DNSSEC
    validation returns bogus or indeterminate.

Getting (1) is probably trivial (though with middleboxes you never
know), and it seems fairly clear that a pinning scheme can provide (2).
(3) is more subjective and may be hard for us to make any definitive
statements about, hence my proposal to exclude it for now.

-Ben

[1] I feel comfortable consolidating the TLS server operator with the
maintainer of the DNS entr(y|ies) for that server, since the TLSA entries
must reflect the operational reality of the TLS server, and if the two
entities are in conflict either can trivially cause an outage.