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

[Nico Williams <[e-mail]>]

On Tue, Apr 10, 2018 at 11:48:58AM -0500, Benjamin Kaduk wrote:
> 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.

I don't think that's necessary for settling this LC, but let's follow
this for now:

> Your text above seems to imply that you see the goal of the document
> as being a security mechanism to DANE-authenticate TLS connections.

Without precluding DANE + WebPKI.

> 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.

The last-mile problem described in the last sentence in the above quote
is the most important point.

This extension is not merely an optimization so that the client need not
perform those additional DNS queries: it is a workaround to the
last-mile problem.

Moreover, this isn't just a run-time optimization, but also a developer
optimization.

Lastly, sometimes run-time and/or developer optimizations are actually
necessary to get traction.

>    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

(2) -> this extension is for clients to be able to use DANE when they
otherwise could not.

In order to be able to mix WebPKI and/or DANE, it is necessary to have
the proofs of non-existence in order to be able to decide to dispense
with DANE.  Therefore this isn't just an optimization for when you want
to use DANE: it is for when you are willing to use DANE, and willing to
not do DANE, but you need to know which to do.

It is because the choice is WebPKI and/or DANE that the downgrade
attack, and the pinning mitigation (with TOFU semantics) matter.

For example, on the web, in IMAP, ..., the WebPKI *and* (not *or*) DANE
usage (DANE usages PKIX-TA #0 and PKIX-EE #1) are likely to matter.

> 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 don't follow.  The security role for DANE here is the whole story, and
it is essential.  How can we say that this is just about latency or
last-mile problems when what DANE is doing at the end of the day is...
provide authentication (security).

> 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.

Again, my concern is that the follow-on will not happen.  I don't
believe the authors are interested in it.  It is perfectly possible that
without this "feature" in on day one it may never get added because
people throw their hands up and move on.  This happens in our industry.

But what really bugs me is that the only reason anyone seems to want to
avoid these minimal changes is "so we can be done already".  After 16
years of participation at the IETF, I find that... a bit surprising.

It's not that we never shoot-the-engineers-and-ship, but that we try not
to have glaring problems in our specs.  We're the sort of SDO that has
enough review to find and fix such problems, and we're a large
community, and we try to serve that community's needs, not just each
draft's authors' immediate needs.

> 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.

OK:

  We need a general-purpose extension for stapled-DANE in TLS.

  Because for many (all existing) TLS applications this is an upgrade,
  we also need downgrade protection.  Full stop.  To me this is
  self-evident, and I don't understand how it is not to anyone else,
  except because of an urge to "be done", and I don't see how that could
  possibly be justification.

FYI, I've had to go back to a WG before to correct a problem post-IESG
approval.  It happens.  It's not a big deal.  We'll almost certainly
spend more time and effort arguing about this than about actual proposed
text.

Nico
--