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

[Benjamin Kaduk <[e-mail]>]

Hi Viktor,

With no hats.

On Tue, Apr 10, 2018 at 10:20:01AM -0400, Viktor Dukhovni wrote:
> 
> 
> > On Apr 10, 2018, at 9:48 AM, Shumon Huque <[e-mail]> wrote:
> > 
> > But I would also like to publish a document that has the solid
> > consensus of the community that is one of key potential target
> > consumers of this draft (web browsers and servers). So I'm giving
> > more weight to their views and preferences. To date, the only
> > people from that community that have spoken up have expressed
> > strong opposition to Viktor's proposed enhancement.
> 
> There'll be negligible adoption of this draft as-is by Web Server
> operators on the public Internet.  It offers them all pain and no
> gain.  ZERO additional security over and above what they get with
> Let's Encrypt, only additional operational complexity and a new
> way to fail when the client supports DANE and the TLSA records
> are stale.

I'd like to expand the discussion a little bit, on the question of
what the goals of this document are, as well as that they should be.
Your text above seems to imply that you see the goal of the document
as being a security mechanism to DANE-authenticate TLS connections.
But it's not clear to me that this is the best reading of the current
document text.  Re-quoting some text you had included in the thread
previously:

   [...] The intent of this
   proposal is to allow TLS clients to perform DANE Authentication
   [RFC6698] [RFC7671] of a TLS server without performing additional DNS
   record lookups and incurring the associated latency penalty.  It also
   provides the ability to avoid potential problems with TLS clients
   being unable to look up DANE records because of an interfering or
   broken middlebox on the path between the client and a DNS server
   [HAMPERING].  And lastly, it allows a TLS client to validate the
   server's DANE (TLSA) records itself without needing access to a
   validating DNS resolver to which it has a secure connection.

   This mechanism is useful for TLS applications that need to address
   the problems described above, typically web browsers or SIP/VoIP
   [RFC3261] and XMPP [RFC7590]. [...]

I'd like to see if we can agree on what "the problems described above" are.
I am reading the quoted text to say that the problems are:

1) needing to incur additional latency by doing DNS lookups
2) interfering/broken middleboxes that drop DANE records
3) needing a secure connection to a validating resolver

While it is true that performing DANE Authentication generally does have
a security role, the three items I list above are essentially matters of
convenience, and not themselves relevant for security.  In this sense, the
immediate goal of the document is more to play a role as a transport than to
provide security directly.

I concede that it remains useful to consider what the client will do
with the received DANE records or denial thereof, so as to not unduly
block off future routes for development.  But it seems at least possible to take
a very broad view in this space, including even the possibility of additional
TLS extensions that can modify the behavior of this one (such as a modification
to provide pinning-like behavior).  Such extensions could be introduced closer
in time to when the desire to implement and use such behavior appears.

So, can we ask ourselves what we intend to get from the document?  I suspect
that the vehemence of disagreement being presented stems from a disagreement
in the goals we are seeking to achieve.

-Ben