Re: [dane] domain hijacking

Alice Wonder <alice@domblogger.net> Thu, 13 April 2017 12:38 UTC

Return-Path: <alice@domblogger.net>
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 45B8613159A for <dane@ietfa.amsl.com>; Thu, 13 Apr 2017 05:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=domblogger.net
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 M0sBG7p_BjX7 for <dane@ietfa.amsl.com>; Thu, 13 Apr 2017 05:38:50 -0700 (PDT)
Received: from mail.domblogger.net (mail.domblogger.net [104.200.18.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1CE129423 for <dane@ietf.org>; Thu, 13 Apr 2017 05:38:50 -0700 (PDT)
Received: from localhost.localdomain (68-189-44-253.dhcp.rdng.ca.charter.com [68.189.44.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.domblogger.net (Postfix) with ESMTPSA id 9CDB61E67 for <dane@ietf.org>; Thu, 13 Apr 2017 12:38:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=domblogger.net; s=default; t=1492087129; bh=fqFiuDX/a1zqn8/fMPc8LKZHLW2GK7yAjtpFefN1Dn0=; h=Subject:To:References:From:Date:In-Reply-To; b=q2zTrmaacjAsKx4zypJKwouV4x+96QkjdtM0fODnn9cRNcmbOgDG7KokOIpKoVRVV a4pzg2eH5slxPexV4u0OmEwnXiMbKZ2QSlahItr46snKfdm4fcoM9cwQ09nEOEF8k+ bkXBVn8oGa658P6pZao3KX4YQYwMfTPZ8twXs3Ko=
To: dane@ietf.org
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> <1492086441.2469.30.camel@wemonitoremail.com>
From: Alice Wonder <alice@domblogger.net>
Message-ID: <fce7b781-c95d-8c71-0235-63e0abfb2d75@domblogger.net>
Date: Thu, 13 Apr 2017 05:38:48 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <1492086441.2469.30.camel@wemonitoremail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dane/euZF62TP9UMfn0WriJmUwDPH0AI>
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:38:51 -0000

On 04/13/2017 05:27 AM, Ken O'Driscoll wrote:
>
> 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.

What I am suggesting is that a CSR be produced from the KSK.

That CSR gets signed by a third party - either OV or EV (no point in DV)

The resulting x.509 cert is sent as part of the TLS handshake.

If it doesn't match the DS record in zone's parent the client refuses.

If it matches the DS record in zone's parent then the client shows the 
pretty OV or EV information in the URL bar.

That won't stop someone who takes over a zone but it will prevent them 
from doing so with the extra EV validation users like me always look for 
when going to our bank or twitter or whatever.

So if Chase has their zone hijacked in the registry, the attacker could 
make a DNSSEC validating phishing site, but it wouldn't have the other 
visual indications of EV because the attacker wouldn't be able to send a 
signed X.509 from the KSK that matches the fraudulent DS records they 
created.

Wouldn't stop MITM from being attempted but it would give at least some 
users a visual indication that things are not what they are suppose to be.