Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt
Bjørn Mork <bjorn@mork.no> Sun, 04 November 2018 14:11 UTC
Return-Path: <bjorn@mork.no>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E454B12D4EC; Sun, 4 Nov 2018 06:11:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mork.no
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 QdTLvGrMnk6o; Sun, 4 Nov 2018 06:11:00 -0800 (PST)
Received: from canardo.mork.no (canardo.mork.no [IPv6:2001:4641::1]) (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 A84CC120072; Sun, 4 Nov 2018 06:10:59 -0800 (PST)
Received: from miraculix.mork.no (miraculix.mork.no [IPv6:2001:4641:0:2:7627:374e:db74:e353]) (authenticated bits=0) by canardo.mork.no (8.15.2/8.15.2) with ESMTPSA id wA4EAt8P003932 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 4 Nov 2018 15:10:56 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1541340656; bh=LuzHV4tBD+43UQXDMX+YCtQI6iqHpzEZTXBIA/YeNY4=; h=From:To:Cc:Subject:References:Date:Message-ID:From; b=Y5cr39PILb6Qdw5Pj4sT9KN5ON4o2dAuj8sg2hadxoU+cl3HpUSLYTADqKtH/0umo 5Dbt+E32tQ7VyCZlcgP392/6PV4Yzs8ZatoHGWh8oLOrF4GMXXDl08VfI5KWujcuaY xf0CxnFCkwXR5hsQyReohvlM5f8fD3O6rp3anHnU=
Received: from bjorn by miraculix.mork.no with local (Exim 4.89) (envelope-from <bjorn@mork.no>) id 1gJJ79-0005Ja-5a; Sun, 04 Nov 2018 15:10:55 +0100
From: Bjørn Mork <bjorn@mork.no>
To: internet-drafts@ietf.org
Cc: i-d-announce@ietf.org, dnsop@ietf.org
Organization: m
References: <154127656499.10164.10170177869879078794@ietfa.amsl.com>
Date: Sun, 04 Nov 2018 15:10:55 +0100
In-Reply-To: <154127656499.10164.10170177869879078794@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Sat, 03 Nov 2018 13:22:45 -0700")
Message-ID: <87efc1rl00.fsf@miraculix.mork.no>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: clamav-milter 0.100.2 at canardo
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IUveUACKcHZdsaA1BKTxx9Adi0U>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Nov 2018 14:11:03 -0000
Section 4.3 claims RFC7671 reserves "_dane": " +------------+------------------+------------+ | RR Type | _NODE NAME | REFERENCE | +------------+------------------+------------+ .. | TLSA | _dane | [RFC7671] | " I can't see any support of this in RFC7671. I assume the misunderstanding comes from a couple of examples using a "_dane" label. But this is an arbitrary choice, and not an attempt to reserve a name. For example from RFC7671 section 5.2: " Some domains may prefer to avoid the operational complexity of publishing unique TLSA RRs for each TLS service. If the domain employs a common issuing CA to create certificates for multiple TLS services, it may be simpler to publish the issuing authority as a TA for the certificate chains of all relevant services. The TLSA query domain (TLSA base domain with port and protocol prefix labels) for each service issued by the same TA may then be set to a CNAME alias that points to a common TLSA RRset that matches the TA. For example: ; Two servers, each with its own certificate, that share ; a common issuer (TA). ; www1.example.com. IN A 192.0.2.1 www2.example.com. IN A 192.0.2.2 _443._tcp.www1.example.com. IN CNAME tlsa._dane.example.com. _443._tcp.www2.example.com. IN CNAME tlsa._dane.example.com. tlsa._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14... " It is obvious from this that "tlsa._dane.example.com." is a placeholder alias, and not reserving "tlsa" or "_dane" labels. The consistent choice of "tlsa._dane" in the RFC7671 examples might have contributed to this confusion. Something to keep in mind for future DNS label examples. Use your fantasy :-) Bjørn
- [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.… internet-drafts
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf… Warren Kumari
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf… John R. Levine
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf… Bjørn Mork
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf… Dave Crocker
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf… Erik Kline
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf… Dave Crocker
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf… Erik Kline
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf… Ray Bellis
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf… Dave Crocker