Re: [DNSOP] The DNSOP WG has placed draft-ogud-dnsop-maintain-ds in state "Candidate for WG Adoption"

Jan Včelák <> Sun, 08 November 2015 20:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4C1EB1B34C6 for <>; Sun, 8 Nov 2015 12:50:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gZBkSiCKxmbc for <>; Sun, 8 Nov 2015 12:50:03 -0800 (PST)
Received: from ( [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B41051B34C4 for <>; Sun, 8 Nov 2015 12:50:03 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id EBB6A18187E; Sun, 8 Nov 2015 21:50:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1447015801; bh=FVFXQaudloIfSLa6WaXIn2qAmjyf/UV/fEhY/lNO/IM=; h=To:From:Date; b=EVOIdNPBatJaVQ4IGjLmXdvW2VXqh0WELP2ixsX9+ktTwtPxigbGb1PPJ1Y8tcwEd /3DIPIhJKYtgwNPOFHMH0DzpLaWUcQs2iS7iA9lD7kGeFbeLJ31XU1O6KhR+szmObm JTGXLkKxmQQZ03whEiCMKDzMnUynG5dvL7oGlfZk=
To: Olafur Gudmundsson <>, Shane Kerr <>
References: <> <> <>
From: Jan Včelák <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Sun, 08 Nov 2015 21:49:56 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [DNSOP] The DNSOP WG has placed draft-ogud-dnsop-maintain-ds in state "Candidate for WG Adoption"
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 08 Nov 2015 20:50:05 -0000

>> * Perhaps "Accept with challenge" should provide some advice on how
>>  this works. For example, a TXT record with a unique key for each zone
>>  (or customer) seems like a good recommendation. It might also make
>>  sense if each child domain (or customer) has a unique ownername to
>>  look for, to prevent 3rd parties from detecting such bootstrapping.
>>  (Yes a 3rd party can see the CDS update followed by the DS update,
>>  but they won't know the verification used.) Also to note that after
>>  the trust is established that the challenge record should no longer
>>  be necessary and can be removed.
> There are many different ways to do this
> a) generate a random name with a  <type>  record with defined content 
> b) put a <type> record at a fixed name with random content 
> c) require resigning the CDS/CDNSKEY record with defined expiration time 
> etc. it is just a question of imagination what people come up with. 
> If the working group wants to recommend one standard way, that is fine. 
> Text welcome

The value determined by the parent need not be random but can actually
authenticate the CDS RDATA content. What about something like this:


Parent instructs the requestor to add a TXT RR into the zone with owner
name matching the zone name prefixed with the '_cds' label. The RDATA of
the record contain a value determined by the parent and provided to the
client by a secure channel (e.g. domain registration system).

The parent constructs the value as follows:

HEX(HMAC-SHA256-64(parent_secret, cds_owner|cds_rdata))


- HEX is a conversion from binary to lowercase hexadecimal digits.
- HMAC-SHA256-64 is an authentication code as specified in RFC 6234.
- server_secret is a cryptographically strong secret key known only
  to the parent.
- cds_owner is the wire format representation of the child zone name
  in the canonical form.
- cds_rdata is the wire format representation of the CDS RDATA in the
  canonical form.


However, this trust establishing dance still requires interaction with
the parent via an out-of-band channel. So there is a little difference
from giving the parent the initial DS records directly.