Re: [dane] domain hijacking

Alice Wonder <alice@domblogger.net> Thu, 13 April 2017 06:04 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 BD388128D3E for <dane@ietfa.amsl.com>; Wed, 12 Apr 2017 23:04:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.103
X-Spam-Level:
X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 0E2ZBLOHjRXH for <dane@ietfa.amsl.com>; Wed, 12 Apr 2017 23:04:23 -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 0F4F61293E9 for <dane@ietf.org>; Wed, 12 Apr 2017 23:04:22 -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 DE82611F1 for <dane@ietf.org>; Thu, 13 Apr 2017 06:04:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=domblogger.net; s=default; t=1492063462; bh=T7QxIRQ61t5S8CXvoRm9t/KRk2FTyPJBXs5SI6Y27Cs=; h=Subject:To:References:From:Date:In-Reply-To; b=juxyNEXgwtxKLHfRiE1cemHwoBhgU5JmpeLnWbtxaBt1PwqF9I+eRVA1a9bQoxPNo 03FbYGqvv9r7xq1z7Z2oOKjD+2u2hIl+qKVzQHoMGqPsQM+lf4tCBmjXApj7Hu7Q7r 0ZedUONJLcVOMITGCHhW2OcnAE0PpcrE46APJ/fw=
To: dane@ietf.org
References: <20170413031124.79969.qmail@ary.lan> <5e781877-0c0c-5d11-2c64-3e66c0fd6f21@domblogger.net> <428eca20-a5b9-26e8-3f67-bc3ce770acf2@domblogger.net>
From: Alice Wonder <alice@domblogger.net>
Message-ID: <6a605bbc-6c19-94de-b0fc-dcd49c946f67@domblogger.net>
Date: Wed, 12 Apr 2017 23:04:20 -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: <428eca20-a5b9-26e8-3f67-bc3ce770acf2@domblogger.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dane/tvSplTded1GmGWa4uLTCmgafA6U>
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 06:04:25 -0000

On 04/12/2017 10:04 PM, Alice Wonder wrote:
*snip*
>
> Meant to type "third party *signed* DS records"

Okay this is how I would do it. I'm new to list and kind of a nobody but...

DANE is used to secure the long-term private key as an alternate to 
commercial DV certificates.

For OV and EV level of confidence - a company can get an x.509 
certificate using their zone as the CN and extensions specifying the DS 
records that is signed by a trusted third party commercial CA.

This x.509 is only used as verification that the DNSSEC validated DS 
records are genuine and to give the consumer confidence the zone has 
been validated using OV or EV standards. It does not replace DS records 
secured by DNSSEC, only adds a second validation in addition to DNSSEC. 
Only OV and EV make sense for this type of x.509.

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.

I'm not an expert on TLS but I think this would even work with existing 
TLS, just send this x.509 along with the DANE protected x.509 as part of 
the TLS handshake.

Would that work and solve the problem?