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

[Nico Williams <[e-mail]>]

On Fri, Apr 13, 2018 at 12:16:43PM -0700, Jim Fenton wrote:
> From reading the abstract and introduction to this draft, it appears to
> be proposing mostly a performance improvement for retrieving web pages
> using DANE authentication. There is some security improvement, but that
> seems to be incidental to the performance improvement. That would argue
> in favor of publishing the draft as-is. However:

It's not just a performance improvement.  It's also a last-mile
technology: for clients that cannot perform DNS lookups due to being in,
e.g., hotel networks.  And it adds security.

Using DANE adds security, that's for sure, since one can then rely on
both, PKIX *and* DNSSEC, which can only add security.  Or, if one does
not trust the WebPKI, then only DNSSEC.  I have no opinion as to which
of WebPKI alone, WebPKI + DNSSEC, or DNSSEC alone, is best, but I have
an opinion as to who ought to decide that: the server operator.  This
document gives the server operator that power, but it does not give the
server operator any power over client pinning behavior, which means that
operators will not turn this on for apps where it's not mandatory.

That is, without revision, this document really does not help security
as much as with a rather minor revision.  We should want that minor
revision because the (at-this-time-intangible) gain is potentially
large, while the (at-this-time-intangible) cost/risk of not making that
revision is equally large.

> From the discussion I have read, there seems to be disagreement about
> what even the semantics of this pinning would be. And if it's unclear to

Among proponents there are no disagreements over pinning semantics.
Pinning would be only to the use of the _extension_, not to the use of
DANE, nor to any particular DANE usage.  That is, if the server does not
have TLSA RRs, it could still use this extension [to satisfy a client
pin] to send the denial of existence proof, and the client's pin would
be satisfied.

> the WG participants, it's going to be even less clear to others that are
> implementing this. I am also of the opinion that pinning is somewhat

How would that follow?  Shouldn't we see proposed text before we can
tell if it would be unclear to implementors?

> subtle; it requires a detailed understanding of the mechanism to remove
> (expire) the pin, and if done wrong can result in availability problems.

Exactly!

(A) gives us a modicum of pin-clearing capability: if you get a denial
of existence then you could clear the pin on the client.

However, (A) + (B) (i.e., (C)) would give us the ability to separate the
pin set/clear from the DNSSEC payload of the extension.  *This* would
give server operators all the control they need to feel safe enabling
pinning behavior.

It is much simpler to change a TTL in a server configuration than to
make changes in the relevant DNS zone(s).  Thus (C) or some (C') (see
below) would be much better than (A).

> In addition, the pins here would be maintained in individual browsers.

And other user-agents for other application protocols (e.g., MUAs).

> There is less benefit from pinning because unlike some other pinning
> mechanisms, there isn't any leverage of the TOFU experience had by others.

TOFU works reasonably well.  It's risky for an attacker to mount an
active attack that will be detected if the client has a pin -- this risk
acts as deterrent.

> This requires further thought, and I do not support adding pinning to
> this draft. Perhaps as a separate draft, but the WG needs to decide on that.

I wouldn't mind a (C'): a variant of (C) where we get denial of
existence and a one- or two-byte TTL (one by count of weeks or two-byte
count of hours) with de minimis text about it, leaving pinning semantics
to a separate document.  In such a (C') we'd elide all pinning (or most*)
in this document.

* We might want to say that if the TTL is zero then the clients MUST NOT
  pin and must clear any pin.  And we might do this in spite of not
  describing any pinning semantics -- explicitly leaving pinning
  semantics to a future document.

Nico
--