Re: [dnsext] [dns-operations] BlackHat Presentation on DNSSEC Downgrade attack

Peter Thomassen <peter@desec.io> Sat, 13 August 2022 19:07 UTC

Return-Path: <peter@desec.io>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD25C157902 for <dnsext@ietfa.amsl.com>; Sat, 13 Aug 2022 12:07:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=a4a.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDjfDb9YGXXJ for <dnsext@ietfa.amsl.com>; Sat, 13 Aug 2022 12:07:33 -0700 (PDT)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (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 B2739C14CF04 for <dnsext@ietf.org>; Sat, 13 Aug 2022 12:07:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:Subject:From :References:To:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=DtFrxdk8kbK8ekNXWuW/lG0OdLC+1/Zq7S0faosayl4=; b=hNShd1PLvX3zUUToFuqbrabHsd KPASWGxrSKHctJv+RzLBRuHPhsI/CMw+QF5naUlUViFwaQdrKVHAkLGiu+20tNNRMZMbn6lJWotTm Hqofo7kcy3ja9ECzDsCBdBxNqBM0t337/9pg+Rq7MG8fIilT1tF6DMcju1CMdeYZqP5SK2iPXBrIk McbO7904dIoCKgEdlmsI5paSP0p35p34jTqn4nIOsp2e0xXbYKhoWTf/zPpkg6uwBQCrbPaq3+BNy 8WCz/IFuKBAWHN6dwGDnvsRev/U1BtUHhqEAjYe62Cstk9UAwcr7f6UOLhGD26ZMxFrMEexMKgBL/ Xma094eg==;
Received: from [2600:1700:4cb0:7ea0:12ca:3eca:37f7:c562] by mail.a4a.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <peter@desec.io>) id 1oMwTk-0007YH-8r; Sat, 13 Aug 2022 21:07:24 +0200
Message-ID: <ff21b6cd-caf3-7276-1ac3-853bf2d593d9@desec.io>
Date: Sat, 13 Aug 2022 15:07:22 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Content-Language: en-US
To: Phillip Hallam-Baker <hallam@gmail.com>, "dns-operations@dns-oarc.net" <dns-operations@dns-oarc.net>, "dnsext@ietf.org" <dnsext@ietf.org>
References: <SN4PR17MB5814C07D06BEBAE9BB3B043CF8649@SN4PR17MB5814.namprd17.prod.outlook.com>
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <SN4PR17MB5814C07D06BEBAE9BB3B043CF8649@SN4PR17MB5814.namprd17.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsext/1IMWRSepj6fhe-ckIWeiqmpS8Ik>
Subject: Re: [dnsext] [dns-operations] BlackHat Presentation on DNSSEC Downgrade attack
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsext/>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Aug 2022 19:07:38 -0000

Hi,

On 8/11/22 17:56, Phillip Hallam-Baker wrote:
> Looks to me like there is a serious problem here.
> 
...
> 
> Won’t go into extreme detail here as researcher’s slides will be available tomorrow.

The slides are now available: http://i.blackhat.com/USA-22/Thursday/US-22-Heftrig-DNSSEC-Downgrade-Attacks.pdf

For the benefit of all, in a nutshell:

a) Slides 1-21 and 32-35: DNS/DNSSEC intro, refresher on IETF-recommended algorithms

b) Slides 22-25: Attacker generates DNSKEY with colliding DS record, then takes over zone
	--> assumes very broken DS digest algorithm
	--> if multiple digest types present, this allows "downgrade" to "weakest" (whatever that means)

c) Slides 26-31: Attacker generates RRSIG without knowing private key, then takes over zone
	--> assumes very broken signing algorithm
	--> if multiple algorithms present, this allows "downgrade" to "weakest" (whatever that means)

d) Slides 36-43: Attacker strips RRSIG or rewrites algorithm, so validator receives only unsupported algorithm
	--> some resolvers pass this as "insecure" instead of "bogus" (even when DS indicates a supported algorithm)
	--> these are implementation bugs at some resolver operators (should be fixed)
	--> Google/Cloudflare bugs originally discovered by Nils Wisiol, sparking further analysis*

e) Slides 44-47: Attacker strips all DNSKEY/RRSIG but one, so validator receives only unsupported DNSKEY/RRSIG
	--> some resolvers pass this as "insecure" instead of "bogus" (even when DS indicates a supported algorithm)
	--> these are implementation bugs at some resolver operators (not sure if fixed)

f) Slides 48-51:
	--> Recommendation and wrap-up: RFCs need some clarification for d) and e)

On 8/11/22 17:56, Phillip Hallam-Baker wrote:
> NSEC record specifies what is signed but not the algorithm used to sign. DNSSEC allows multiple signature and digest algorithms on the same zone. If a zone does this, validators are prohibited from rejecting records only signed using one of the algorithms rather than both.
> 
...
> 
> This definitely needs fixing.

I agree that the specs should more clearly say that when a validating resolver sees a (supported?) algorithm in DS without seeing corresponding RRSIG authenticated via such DS record, the response MUST be bogus.

Apart from that: What else needs fixing? (You mentioned something with NSEC.)

Best.
Peter


* Further analysis occurred in collaboration with the Black Hat authors, but led to disagreement. The collaboration ended, and a flawed paper [1] was later uploaded on arXiv by the Black Hat authors. As it had Nils' and my name, but not our consent, we had the paper withdrawn. Besides the numerous technical and editorial errors in the paper, we in particular disagree with the conclusion that DNSSEC algorithm agility causes the problems. It's just bugs.

[1]: https://arxiv.org/abs/2205.10608

Personally, I also don't believe that the claim of Section 5.2.1 has been experimentally demonstrated. It says:
"[...] the adversary manipulates the algorithm number in an RRSIG RRset over DS RRset to some unsupported algorithm. This is required to disable DNSSEC validation of the DS RRset. The adversary manipulates the DS to correspond to its own key-pair. [...] Once this DNSKEY is stored in cache, the adversary can inject any record of its choice. [...]
[...] it immediately affects all the subdomains of the poisoned domain. In particular, the adversary can further create secure delegations for the subdomains using its own malicious key. Launching this attack against Google public DNS would have severe consequences for all the domains under com.." [2]

That would require that a resolver would regard a DNSKEY as trusted based on a DS record that it has not validated, and use that DNSKEY later to generate responses with AD bit for delegated names. While that is conceivable, it is conceptually different from finding d).

At the time when Nils and I were part of the collaboration, the measurement tooling [3] was not capable of this measurement. There is no indication that it was later extended. I will therefore consider that finding a fabrication until the data is made available.

[2]: Original revision of the paper (pre-withdrawal): https://arxiv.org/pdf/2205.10608v1.pdf
[3]: https://github.com/nils-wisiol/dns-downgrade-attack

(In the arXiv metadata, it is recorded that the paper was withdrawn upon request of one of the authors (me), and not because it was found to be inaccurate. Co-authors did not retract the claim from Section 5.2.1, and instead opposed withdrawal until a lawyer got involved. It is peculiar that the claim still was not made in the Black Hat talk, and I'm actually curious to see data that support it.)

-- 
https://desec.io/