Re: [TLS] TLS interim meeting material

Paul Wouters <> Thu, 13 September 2018 04:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5025C130E11 for <>; Wed, 12 Sep 2018 21:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ay-A5S1GNbSr for <>; Wed, 12 Sep 2018 21:29:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 93A76130DCC for <>; Wed, 12 Sep 2018 21:29:48 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 429lzs3WVDz2JV; Thu, 13 Sep 2018 06:29:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1536812985; bh=Cu9rqLCFf5l9UldD+IY/xhOzI9q40wAve6CvX7BF06g=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=nNPRPzH2iqvo6g1AaEem5TXKxXitkf+SVonemnvOdNmx3LdSJ50oI5Wifna/0OV6I ypRCZS0fGeiNqnLLOW30DqCHeN92/wbnlnmYBfDjpxU4Qm+B5fNeU/Ymr4H3ULY6+t vtOGiwV+QLrLJs343qU+U7VamcT/FxHFbAld09ds=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id eR1VcN4_hd8u; Thu, 13 Sep 2018 06:29:42 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Thu, 13 Sep 2018 06:29:42 +0200 (CEST)
Received: by (Postfix, from userid 1000) id DE7AC39D02F; Thu, 13 Sep 2018 00:29:40 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 DE7AC39D02F
Received: from localhost (localhost []) by (Postfix) with ESMTP id D73B6402E520; Thu, 13 Sep 2018 00:29:40 -0400 (EDT)
Date: Thu, 13 Sep 2018 00:29:40 -0400 (EDT)
From: Paul Wouters <>
To: Richard Barnes <>
cc: "<>" <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: <>
Subject: Re: [TLS] TLS interim meeting material
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Sep 2018 04:29:51 -0000

On Wed, 12 Sep 2018, Richard Barnes wrote:

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

You are resolving a TLSA record via a TLS transport.

> A zone owner sent a TLSA record in a TLS handshake.  This document says nothing about what is "published" through any other channel.

DNS does not publish in "channels". TLSA data either exists or do not exist.

> I don't seem to recall you having rebutted that point, though.

I just did it again but was requested explicitely to do so off-list,
which I grudgingly did and where you were CC:ed by the requester so
you have a copy of my answer. The requester has my permission to forward
it to the public list.

> The similarity isn't vague; the problems are identical.  Let's look at the Chrome intent to remove HPKP

You are still treating this extension as a new independent path to a
(private?) DNS store. As otherwise any comparison with HPKP does not
apply. TLSA records are published in DNS. Clients can obtain them via
a variety of transports. One such transport cannot change the meaning
of the transported DNS data.

> There is a risk of rendering a site unusable.

That is unqualified here so I cannot say anything meaningful about it.

> There is a risk of hostile pinning, should an attacker obtain a misissued certificate. While there are no confirmed or rumored cases of this
> having happened, the risk is present even for sites that don’t use PKP.

We explained _many_ times that this does not apply to _extension pinning_.

It is explained in the draft. Whoever controls the DNS controls what
goes into the tls-dnssec-chain data. So the only way this can contain
rogue data is if the zone's DNSSEC is compromised.

If only the web server is compromised, an attacker can put in whatever
they want, it does not matter. As long as they don't also have the
DNSSEC keys of the domain or any of its parents, it cannot put anything
malicious into the extension that will pass DNSSEC validation on the TLS
client. The attacker can also stop publishing the extension completely.
Regardless, the TLS client detects both as a downgrade attack and will
terminate the connection. It will NOT ACCEPT any extension pinning timer
that the hacker put in place because the tls-dnssec-chain extension
either did not validate or contained only meaningless data. This is a
feature, not a bug. We just prevented you from connecting to a
compromised TLS server.

If the attacker ONLY changed the pin value to 7.5 years (the maximum) with
the existing valid TLSA records, then during the time the server sends
this, clients will believe this. But as soon as they reconnect and get a
fresh TLSA record and/or DoE proof, whatever the extension pin setting is
_then_ will be the new pin setting. So the 7.5 years value will be undone
immediately. So as soon as the legitimate TLS server owner takes control
back of the compromised machine and kicks the hacker out, they can put
back the real (old or new) TLSA record in the tls-dnssec-chain extension
or the real Denial of Existence data if the zone owner decided to also
stop publishing TLSA records. This updates anything the client might
have seen in the past because it is authenticated with DNSESC. There is
nothing the hacker could have sent to clients in the past that would stop
the clients from immediately picking up this new tls-dnssec-chain data.

The only exceptional use case would be a TLS client that believed the
7.5 year pin, didn't connect for a long time, and the TLS server admin
deciding to forgo the tls-dnssec-chain extension completely. The admin
followed the draft advise on how to phase out the extension properly,
which includes running with a zero valus for the previous value's time
(weeks or months). And the admin would do this based on their own value
and not the briefly used rogue value. TLS client could interpret that
as a downgrade attack but it would be very obviously something rogue.
This could be mitigated by the TLS client by either doing DNS lookups
via another transport that provides DoE information, such as DoH or
DoT or even plain DNS, or they could prompt the user when encountering
clearly very long pin times in addition with revisiting a server after
an extremely long time. But remember, it is not entirely a bad thing that
this client is finding out it talked to a compromised server in the past,
and he might want to do some remediation before connecting to the real
server again before the banking trojan previously received steals all
their money.

> Both of which are also problems with your pinning proposal.

You cannot say both. You only mentioned one thing. I cannot refute
"There is a risk of rendering a site unusable."  as it does not specify
any specific kind of risk, problem or attack. As opposed to our very
clearly specified and real downgrade attack.

>       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.  And if the server doesn't expect the client
> to cache, then there's no downgrade at all.

If the bouncer at the bar is not expecting fake ID's, there is no downgrade attack
by using fake driver's licenses at all.