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

[Nico Williams <[e-mail]>]

On Mon, Oct 08, 2018 at 05:09:40PM -0700, Christopher Wood wrote:
> Notes from the TLS interim meeting held in September are now online
> [1]. To recap, the meeting attempted to focus on three primary
> questions:
> 
> 1. What is the fundamental security issue? What is the purpose of this
> extension?

Broad utility vs. narrow utility.  As specified the extension is only of
use to clients that can mandate it and hard-fail when it is not
supported.

We are asking for Motherhood and Apple Pie.

Who could disagree?!  And yet many do.  There is a reason for that.

>From the concall and off-list exchanges I believe that the disagreement
with Motherhood and Apple Pie stems from a belief that we can't get them
at an acceptable price.  People have been traumatized by the HPKP
experience and want nothing like it -- and *this* sure is something I
believe we *all* agree on at this time.

Therefore I propose that we put the cart before the horse.

I propose that we start by showing that the proposed Motherhood and
Apple Pie feature is indeed cheap and risk-free, and not HPKP redux.

If we can examine that statement, that the proposal is cheap and
risk-free, and if we can come to agreement on that, then agreement that
we should aim for broad utility will surely follow.

Otherwise, and if no one else has an alternative cheap-and-risk-free
Motherhood and Apple Pie proposal, then we can safely reject broad
utility.

   HPKP is a *footgun*.

Any attempt to add new footguns like HPKP must be rejected.

> 2. Under what circumstances should DNS records received in the
> extension be cached and reused for future use?

The payload contents are DNS responses.  They may be cached, or not, as
usual.  The choice of transport does not affect this.

> 3. Is pinning required? If so, what is pinned, and at what layer(s)
> should it be implemented?

If clients keep no state at all (about the DANE extension) between TLS
handshakes, then the extension can be stripped off (or the client
redirected to a server that won't provide it).  This is the source of
the observation about broad vs. narrow utility.

Now, we cannot, indeed MUST NOT, pin anything that would make this like
HPKP.  Otherwise we'd have a footgun for sure!

That means:

 - MUST NOT pin *any facts* about how the server is to be authenticated!

   Meaning:

    - MUST NOT pin public key material  (private keys get lost, rotated)
    - MUST NOT pin EE certs             (same reason)
    - MUST NOT pin TLSA RRset RDATAs    (same reason)
    - MUST NOT pin intermediate certs   (operator might need to switch CAs)
    - MUST NOT pin trust anchors        (same answer)
    - MUST NOT pin TLSA RRset existence (zone might stop being signed)
    - MUST NOT pin whether the server's RRsets are signed (same)

    - MUST NOT pin any other authentication facts not listed above

That's a pretty extreme list of must-not-pin items.

ALSO: whatever state is kept -whatever is pinned-, the pin must be
      trivial for server operators to clear.

There is only one thing that's left to could get pinned: whether the
server supports the extension, with an expiration time on the pin.

We need to demonstrate that pinning server support for the extension
does not a footgun make.  That's on us.

The test for whether we have a footgun is: can the server operator clear
the client pins trivially in the event of a screwup?  If the server
operator can clear the pins trivially, then we have no footgun.

Well, we have 1 way to set the pin, and 3 ways to clear it.  There must
be methods for clearing the pin that are no more difficult to execute
than setting the pin.

To set the pin:
 - the client MUST have requested the extension
 - the server MUST respond with the extension
 - the server MUST have TLSA RRs and a valid DNSSEC chain
 - the client MUST have authenticated the server per-DANE using the
   attached chain
 - the server MUST have advertised a non-zero pin time

To clear the pin:

 - method #1: Same as setting the pin, server advertises a zero pin time.

 - method #2: Unpublish TLSA RRs or unsign the zone, therefore the
              server MUST send an authenticated denial of existence
              (DoE) back to the client.

              The client then MUST clear the pin after authenticating
              the DoE regardless of whether it successfully
              authenticates the server.

              (Recall that the fact of a zone's not being signed can
              itself be proved in DNSSEC, thus, no longer signing the
              zone leads to authenticated denial of existence.)

 - method #3: Same as method #2, but the client can independently check
              DNS if the server somehow does not support the extension.

              This only works for clients that can reach the DNS, but
              that would be e.g., most browsers, most of the time.  That
              is, this works for clients for which this extension
              functions as an optimization.

              Clients that cannot reach the DNS directly were likely
              ones like DPRIV that want to hard-fail on server
              non-support for the extension anyways.

Because there is a method for clearing the pin involving only local
configuration (#1) no different from setting the pin, and because there
is a method for clearing the pin involving only DNS change control (#2
and #3), including one (#3) where the server need not even support the
extension that it needed to set the pin in the first place...

...there is clearly no footgun: the server operator can clear the pin at
will with less -and in no case more- effort than it took to get the pin
set in the first place.

Now, to be fair there was also discussion of a denial of service attack.

In the DoS attack an attacker who thoroughly compromises the server can
install the extension, set the pin, then uninstall the extension and
watch the server operator suffer.  This also applies to HPKP, and it
never happened, but the HPKP footgun was fired, so the DoS threat in not
realistic just based on experience.  But also, the DoS requires such a
thorough compromise of the server as to make the DoS concern the
operator's least concern.

But suppose the DoS threat weighs heavily on everyone's mind!  Clearly,
if server support for the extension is universal, then the DoS threat
vanishes.

Therefore we offer a mitigation for the DoS case: slow ramped client-
side scaling of advertised pin times.  That is, initially the maximum
advertised pin time could be just hours, and it could stay that way for
N years, then quickly ramp up to a maximum in the range of a few years.
That is, we can make pinning something that comes into force only enough
time into the future that anyone suffering from a DoS before then need
only wait a short amount of time, and anyone suffering from a DoS after
then need only enable a by-then-universally-supported extension.

Surely client-side pin scaling based on time since the extension's
publication as RFC is enough to dismiss the DoS concern entirely.

Thus we have neither footgun nor DoS concerns.

Yes, we can haz Motherhood and Apple Pie.

Q.E.D.

Nico
--