Re: [TLS] TLS interim meeting material
Paul Wouters <paul@nohats.ca> Thu, 13 September 2018 04:29 UTC
Return-Path: <paul@nohats.ca>
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 5025C130E11 for <tls@ietfa.amsl.com>; Wed, 12 Sep 2018 21:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 ay-A5S1GNbSr for <tls@ietfa.amsl.com>; Wed, 12 Sep 2018 21:29:48 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A76130DCC for <tls@ietf.org>; Wed, 12 Sep 2018 21:29:48 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 429lzs3WVDz2JV; Thu, 13 Sep 2018 06:29:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; 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 mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id eR1VcN4_hd8u; Thu, 13 Sep 2018 06:29:42 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 13 Sep 2018 06:29:42 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id DE7AC39D02F; Thu, 13 Sep 2018 00:29:40 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca DE7AC39D02F
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D73B6402E520; Thu, 13 Sep 2018 00:29:40 -0400 (EDT)
Date: Thu, 13 Sep 2018 00:29:40 -0400
From: Paul Wouters <paul@nohats.ca>
To: Richard Barnes <rlb@ipv.sx>
cc: "<tls@ietf.org>" <tls@ietf.org>
In-Reply-To: <CAL02cgQdBkjJuCNwevdVN5hk9XHh-WxNYygkfXPA8STb+peyhw@mail.gmail.com>
Message-ID: <alpine.LRH.2.21.1809122337470.20798@bofh.nohats.ca>
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>
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: <https://mailarchive.ietf.org/arch/msg/tls/LDR3sAQDkIKdsFYH5ru4bMRNLwI>
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 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. Paul
- [TLS] TLS interim meeting material Paul Wouters
- Re: [TLS] TLS interim meeting material Richard Barnes
- Re: [TLS] TLS interim meeting material Paul Wouters
- Re: [TLS] TLS interim meeting material Richard Barnes
- Re: [TLS] TLS interim meeting material Paul Wouters
- Re: [TLS] TLS interim meeting material Viktor Dukhovni
- Re: [TLS] TLS interim meeting material Richard Barnes
- Re: [TLS] TLS interim meeting material Viktor Dukhovni
- Re: [TLS] TLS interim meeting material Eric Rescorla
- Re: [TLS] TLS interim meeting material Salz, Rich
- Re: [TLS] TLS interim meeting material Viktor Dukhovni
- Re: [TLS] TLS interim meeting material Paul Wouters