Re: [DNSOP] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 08 January 2020 17:29 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7776812008A for <dnsop@ietfa.amsl.com>; Wed, 8 Jan 2020 09:29:19 -0800 (PST)
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_HELO_NONE=0.001, SPF_PASS=-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 wYUCdGwj2-4h for <dnsop@ietfa.amsl.com>; Wed, 8 Jan 2020 09:29:18 -0800 (PST)
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 0D1A0120052 for <dnsop@ietf.org>; Wed, 8 Jan 2020 09:29:18 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 64D392B0302; Wed, 8 Jan 2020 12:29:16 -0500 (EST)
Date: Wed, 08 Jan 2020 12:29:16 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop@ietf.org
Message-ID: <20200108172916.GT73491@straasha.imrryr.org>
Reply-To: dnsop@ietf.org
References: <alpine.DEB.2.20.2001071450120.14515@grey.csi.cam.ac.uk> <20200107161808.GG73491@straasha.imrryr.org> <CAN6NTqw7WUWKhKKEydWJSDGxrdSe9qe9bqzBYNTJkq92dgFVDQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAN6NTqw7WUWKhKKEydWJSDGxrdSe9qe9bqzBYNTJkq92dgFVDQ@mail.gmail.com>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/D7srxoPP32sRhaurfyiBDIDVXu0>
Subject: Re: [DNSOP] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2020 17:29:19 -0000

On Wed, Jan 08, 2020 at 08:50:05AM -0800, Ólafur Guðmundsson wrote:

> Due to the structure of DNS records this is hard to pull off,

Yes, at present.

> The only RR types that are suspect are the ones that can have 1440 of
> "garbage" at the end

Yes, at present, but the attacks may continue to improve, perhaps
requiring fewer attacker supplied blocks to reach a collision.

> DS has fixed size so I it can not be used unless someone figures out how
> select blocks that include valid DNS record envelopes.

Yes, while the block count to go from a chosen prefix to a collision is
substantially more than 2.

> TXT will work if the attacker can encode lengths of the individual strings
> into a valid record ==> but who cares about TXT abuse

This is not correct, because with chosen-prefix attacks the two messages
that collide need not share the same owner and type (that's the whole
point of chosen-prefix, the initial segment of the second message can be
freely chosen by the attacker).  Therefore the TXT record can have the
same signature as some more important record, perhaps a fake DNSKEY
RRset for the zone apex!

> DNSKEY is with RSA is good candidate for this attack as any DNSKEY RRset
> for SHA1 algorithms can be attacked by adding a key that sorts to be last
> and is larger than 1440 bits.

But the real DNSKEY RRset is not attacker controlled, whoever creates
the zone's DNSKEY RRs can already subvert the zone content in whatever
way they see fit.  Legitimate signatures of DNSKEYs are not at risk.

> Thus anyone that is using RSA algorithm < 8 should think about key or
> algorithm rollover

Yes, on this we can agree, even though the risk is lower for "leaf"
zones that only sign their own content.

-- 
    
    Viktor.