Re: [dane] domain hijacking

Wei Chuang <weihaw@google.com> Thu, 13 April 2017 14:06 UTC

Return-Path: <weihaw@google.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 8C12B124D68 for <dane@ietfa.amsl.com>; Thu, 13 Apr 2017 07:06:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 5JO0QpGZPDwm for <dane@ietfa.amsl.com>; Thu, 13 Apr 2017 07:06:52 -0700 (PDT)
Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8D8D126FDC for <dane@ietf.org>; Thu, 13 Apr 2017 07:06:51 -0700 (PDT)
Received: by mail-vk0-x22b.google.com with SMTP id z204so28516402vkd.1 for <dane@ietf.org>; Thu, 13 Apr 2017 07:06:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iXQO3mJ2iHtl5+ppkc+EnpSnK08ckUbrE46VWfw45zU=; b=VMEQmhKhC/KfQDQavV7f7mm2hBEYGtssFLJR64XwX9Rlbv7cfCUHThEQbPTxkTNAXL m5DcvRiF+Y23sIkaQY0S4FJoeifoyxoWsaJ8voOFcZf5bEX5il4+TO9YsKK/PbfqmaZP aqTNF2aqhmRsPXhdfU0bO+Ok7XE63q3SoYGTi/96lDXJc2+Ofteg0KdXqHe1j6SLgEe8 jTIEZ+LbdxyV1ek0MbK6MOHjxP2i8yJfBm31pHX4cP9Mi2TcSwMpQvJQ8c8Q3KBU8wa/ wFgwYthhnJ5XYMsePwKLMDn/pyuwCcsX5ziaOGJCcrPSxARgk5Sq0tQg/c6w8CLwUGkj 8p/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iXQO3mJ2iHtl5+ppkc+EnpSnK08ckUbrE46VWfw45zU=; b=hmjalMa5+gq+UuSX29c5qc7v58dkdwZ+5hGMHwzd8RTLnQldSJDdC3/tw4qaXFrPY4 YWq92kUKOCQhoLoK5YbLbEY8AYquX2aUSzyjDq3+eK/X3qcyczXKtKHXcre7NetnyJDz xPmjIEWnscR7TEieYGqJ2M+z9fqaDIdh+YjL+EYEjyhPaM6fN0w1Cp0WJkKeq6CeFZg5 FHZYJ6iwDdLyTNHbjwW+Q9J9N2ZMsoRYwxHKIyUOZofOaVbB5L5IiFw2RGR9r9KHBKL4 mEm1NjzoMjdLsVeE/SnBIm75tDqk6npNhEWBiEq9atMaJHyBsDrzl3DfL0qQRTRX/Ufh YK5A==
X-Gm-Message-State: AN3rC/6r+qzD8vDo8dCs8vhA4JIxiWvbqh5hG13kH0AXhZcdSfgVR7ac XvtSvAB/W6ueLKbpx9QQKjqMQmD9ausAnJ9isQ==
X-Received: by 10.31.153.74 with SMTP id b71mr1313531vke.73.1492092410511; Thu, 13 Apr 2017 07:06:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.51.200 with HTTP; Thu, 13 Apr 2017 07:06:49 -0700 (PDT)
In-Reply-To: <20170413031124.79969.qmail@ary.lan>
References: <CAAFsWK35neS7t_ZXHiTgSuc4wU4dWzEdAxFCzK+k11drvcOOkA@mail.gmail.com> <20170413031124.79969.qmail@ary.lan>
From: Wei Chuang <weihaw@google.com>
Date: Thu, 13 Apr 2017 07:06:49 -0700
Message-ID: <CAAFsWK3eMisaC5JjU6WND3Xx3Q=r08Zb-ijVoapDoG8NtSJcKw@mail.gmail.com>
To: John Levine <johnl@taugh.com>
Cc: IETF DANE Mailinglist <dane@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1141dd30215f3a054d0cd6aa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dane/mMvBSPSBiqBHsxiPNLpobD6g6pw>
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 14:06:55 -0000

On Wed, Apr 12, 2017 at 8:11 PM, John Levine <johnl@taugh.com>; wrote:

> > If my suspicion is correct, has there
> >been thought of re-signing the DS record signed with the older private key
> >in a way that proves ownership through the key change?
>
> This sounds to me like shutting the barn door after the horse is gone.
>
> If it's important to you that your domain isn't hijacked, we all know
> what to do, pick a registrar with good security and 2FA and so forth,

and monitor your own DNS with alarms if there are unauthorized changes.
>

Even with a good registrar there might be some reason for this.  Consider
that 2FA might not  be a permanent solution to zone admin account
hijacking.  For example, RSA 2FA products which are very popular, were
reportedly bypassed back in 2012
<https://arstechnica.com/security/2012/05/rsa-securid-software-token-cloning-attack/>;.
Further such a solution might better detect/prevent spoofing by a
adversarial parent zone or registrar.  Agreed that monitoring is a good
idea.  One issue it that it may be difficult for you/your script to be
always vigilant.  Perhaps by making a domain hijacking more visible to
everyone, and having a whistleblowing (i.e. reporting mechanism such as
used in Coniks) protocol then you could distribute the problem of
monitoring.


>
> Also, if we were to invent some sort of change signing, now you have
> the other problem where the guy with the private key quits and takes
> it with him, and you have to rebootstrap the zone somehow.
>

Agreed this is pertinent issue and I don't have a fully baked scheme to
work out this scenario.  But perhaps a solution might involve checking the
cached but stale result to see if that historic state is consistent with a
newly published state up to 1 TTL period.  Errors condition would then
existing for a finite time (1 TTL).

-Wei