Re: [dane] domain hijacking

"Ken O'Driscoll" <ken@wemonitoremail.com> Thu, 13 April 2017 12:28 UTC

Return-Path: <ken@wemonitoremail.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E14E129416 for <dane@ietfa.amsl.com>; Thu, 13 Apr 2017 05:28:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.793
X-Spam-Level:
X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=wemonitoremail.com
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 oHqpfY9XO8AH for <dane@ietfa.amsl.com>; Thu, 13 Apr 2017 05:28:03 -0700 (PDT)
Received: from mail.wemonitoremail.com (mail.wemonitoremail.com [78.47.26.204]) (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 379CD126DD9 for <dane@ietf.org>; Thu, 13 Apr 2017 05:28:03 -0700 (PDT)
X-WeMonitorEmail-From: ken@wemonitoremail.com
X-WeMonitorEmail-VirusCheck: Clean
Received: from auth (localhost [127.0.0.1]) by mail.wemonitoremail.com (8.14.4/8.14.4/inbound) with ESMTP id v3DCRLvm011410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <dane@ietf.org>; Thu, 13 Apr 2017 13:27:24 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemonitoremail.com; s=mail; t=1492086444; bh=zqIrLB5aVAWi1YBAna5SYO77XbVa2qHzpRI7C5qdmyk=; h=Subject:From:To:Date; b=RpPjKxrqxgL5gX2h49NalS+LPp9xjiXjxSPgNXyL7N9ABqDxkZc6Eqq/BA6FMoaXG 6Tg7csl8qgJOI8e1xjXNzn/BmapOnVzRTkANxu4rEh28nM3b67zHNgxkyo2FB//q9t Vy/wwxrycszh5/YU6bO7qnVMXU0GVgspIlhNggQo=
Message-ID: <1492086441.2469.30.camel@wemonitoremail.com>
From: "Ken O'Driscoll" <ken@wemonitoremail.com>
To: dane@ietf.org
Date: Thu, 13 Apr 2017 13:27:21 +0100
In-Reply-To: <6a605bbc-6c19-94de-b0fc-dcd49c946f67@domblogger.net>
References: <20170413031124.79969.qmail@ary.lan> <5e781877-0c0c-5d11-2c64-3e66c0fd6f21@domblogger.net> <428eca20-a5b9-26e8-3f67-bc3ce770acf2@domblogger.net> <6a605bbc-6c19-94de-b0fc-dcd49c946f67@domblogger.net>
Organization: We Monitor Email
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24)
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dane/TaoE7Ba-oiNUWpm1dXc5U_XFYik>
Subject: Re: [dane] domain hijacking
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Apr 2017 12:28:04 -0000

On Wed, 2017-04-12 at 23:04 -0700, Alice Wonder wrote:
> To compromise a zone protected by this second x.509 a bad actor would 
> need to both obtain a fraudulently signed x.509 from a trusted authority 
> *and* get fraudulent DS records into the zone's parent zone.

Or, an attacker could (as in the case we're discussing) just gain access to
the domain registry and re-assign NS records, disabling any DNSSEC type
security in the process. Resolvers have no expectation to be dealing with
DNSSEC signed zones so removing the protection would not be challenged.

Any mechanism that relies on anything that the registrant controls which
they (or an imposter with their credentials) can disable does not address
this risk.

As John already pointed out, organisations can mitigate against these
attacks by choosing registries (and registrars) who offer robust
authentication options along with employing monitoring solutions.

I'm not seeing how any type of protocol can do away with normal operational
level security.

Ken.