Re: [TLS] TLS interim meeting material

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 13 September 2018 14:59 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6493C130DC8 for <tls@ietfa.amsl.com>; Thu, 13 Sep 2018 07:59:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z54SD4nwNnK8 for <tls@ietfa.amsl.com>; Thu, 13 Sep 2018 07:59:09 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 160C912D7EA for <tls@ietf.org>; Thu, 13 Sep 2018 07:59:08 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 1468D37E7B; Thu, 13 Sep 2018 10:59:07 -0400 (EDT)
Date: Thu, 13 Sep 2018 10:59:07 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20180913145906.GF3589@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <alpine.LRH.2.21.1809121721300.5141@bofh.nohats.ca> <CAL02cgTZ25jAPUkFYLMQWztz9OLstMHkQHFpJ8YLy5KEd39tOg@mail.gmail.com> <alpine.LRH.2.21.1809122030200.7975@bofh.nohats.ca> <CAL02cgQdBkjJuCNwevdVN5hk9XHh-WxNYygkfXPA8STb+peyhw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAL02cgQdBkjJuCNwevdVN5hk9XHh-WxNYygkfXPA8STb+peyhw@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kwXftA--GD0lSr00SsjP9DhAbQg>
Subject: Re: [TLS] TLS interim meeting material
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2018 14:59:11 -0000

On Wed, Sep 12, 2018 at 10:40:31PM -0400, Richard Barnes wrote:

> > DNS records have semantics beyond a single connection.
> 
> DNS records have caching semantics.  Those are only relevant for DNS
> resolution.  This is the TLS WG, not the DNS.

It's odd you should say that, in draft -07, which you coauthored,
I see the below rather reasonable text:

   https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07#section-6

   Clients MAY cache the server's validated TLSA RRset or other
   validated portions of the chain as an optimization to save signature
   verification work for future connections.  The period of such caching
   MUST NOT exceed the TTL associated with those records.  A client that
   possesses a validated and unexpired TLSA RRset or the full chain in
   its cache does not need to send the dnssec_chain extension for
   subsequent connections to the same TLS server.  It can use the cached
   information to perform DANE authentication.

> > A zone owner published a TLSA record.
> 
> A zone owner sent a TLSA record in a TLS handshake.

No that's the TLS server application, the TLSA record is in fact
published as part of the DNS zone independently of what the TLS
application might later do.  The data is signed at the origin and
can be transmitted over any number of channels and verified at the
destination.

> This document says nothing about what is "published" through any
> other channel.

Because DNSSEC handles both data authentication, and authenticated
denial of existence, the same facts are conveyed about any requested
RRset, regardless of channel.  Unlike other contexts, alternative
facts are detected as "bogus".

> The similarity isn't vague; the problems are identical.  Let's look at the
> Chrome intent to remove HPKP
> 
> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ?hn

But HPKP is vastly different.  It pins keys, which if never possessed
or lost by the legitimate site operator, preclude the operator from
restoring communication with the client.

Indeed though the issue is typically described as a risk of DoS by
a malicious adversary, the *real* and far more common problem with
HPKP is self-inflicted damage after loss of keys through operational
errors or hardware failure.

Here, all that would be "pinned" is a capability to support the
extension, which anyone could enable at their pleasure, and the
self-inflicted damage is entirely out of the picture, just bring
the service back online and it continues to work!  Delivery of fresh
TLSA records or denial of existence updates or clears any previous
pin with friction.

Furthermore, a client that sees a server violating its pin, rather
than failing, can then choose to pay the latency cost and obtain
valid DNSSEC signed TLSA RRs from 1.1.1.1 or similar DNSpriv servers
(where the extension would be unconditionally supported, as part
of DANE support in DNS over TLS or DNS over HTTP).  If the TLSA
records are proved to not exist, the client can clear the pin.  If
the TLSA records exist and match the server's certificate chain,
the client can continue the connection.

> There is a risk of rendering a site unusable.

This risk is vastly lower for this protocol, and tamper-evidence
that shows that past connections were to a rogue server is frankly
a feature more than a bug.  The user is now informed that he was
previously, or is now, communicating with the wrong server, and
that some action may be required to secure his data.

> There is a risk of hostile pinning, should an attacker obtain a misissued
> certificate.

This is the dramatic strawman version of the risk.  The real problem
is irrecoverable loss of keys.

> While there are no confirmed or rumored cases of this having
> happened,

Precisely, because the real problem is loss of keys, which surely
did happen.

> the risk is present even for sites that don’t use PKP.

This is the strawman risk that sells the deprecation, the real
reason is much more mundane.

> > Any client that obtains DNS data with a valid TTL is allowed to cache
> > and re-use it as long as the TTL allows it. Irrespective of whether this
> > is part of TLS or Aviation Carriers.
> 
> The client may do that.  That doesn't mean the server is entitled to expect
> the client to do that.

Nobody is saying the client has to cache, and indeed the server
cannot expect the client to be stateful.

> And if the server doesn't expect the client to
> cache, then there's no downgrade at all.

The above is a failure of deductive reasoning.

-- 
	Viktor.