Re: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-02.txt
Petr Špaček <petr.spacek@nic.cz> Wed, 21 February 2018 14:54 UTC
Return-Path: <petr.spacek@nic.cz>
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 25B7D1270AB for <dnsop@ietfa.amsl.com>; Wed, 21 Feb 2018 06:54:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level:
X-Spam-Status: No, score=-7.01 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_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 zEDpOxzJj26i for <dnsop@ietfa.amsl.com>; Wed, 21 Feb 2018 06:54:49 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 D0F58126DFB for <dnsop@ietf.org>; Wed, 21 Feb 2018 06:54:48 -0800 (PST)
Received: from [IPv6:2001:1488:fffe:6:e8c1:e0ff:fefd:713] (unknown [IPv6:2001:1488:fffe:6:e8c1:e0ff:fefd:713]) by mail.nic.cz (Postfix) with ESMTPSA id 2D1386256D; Wed, 21 Feb 2018 15:54:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1519224887; bh=ujvUcyTWXLTQzf3csm8L5DpzOpNvjIKmn7cbtfsOkig=; h=To:From:Date; b=a01Drh+Z+KtKOcyKy6ZBNGtTteS2O98gLRHAtvVqfHWoE52O6ZFtBZGyiOgMtI0+h a1beU+9wGxh4CUEFpu88aV9gUkmP/lr+81V6k+gPiyhVf45ha9VvKHUlYWk2QogqJC Iudes5csDgKKUIT0E8mFtMbJEqlFoMWyrYktSiow=
To: dnsop@ietf.org, Warren Kumari <warren@kumari.net>
References: <151922179001.9848.13840482767119778239@ietfa.amsl.com>
From: Petr Špaček <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <34700c32-785b-a962-db04-5372c76f7da6@nic.cz>
Date: Wed, 21 Feb 2018 15:54:46 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <151922179001.9848.13840482767119778239@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/sAD2a20auxefDjXeUt1LnZl__8s>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-02.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 21 Feb 2018 14:54:52 -0000
Hello dnsop and Warren, Section 3. Sentinel Mechanism gave me hard time while implementing this mechanism, so I'm proposing to overhaul the section into something with more structure. Proposal: (Feel free tp change and restructure it as you see fit, I'm not native English speaker ...) 3. Sentinel Mechanism DNSSEC-Validating resolvers that implement this mechanism MUST be performing validation of responses in accordance with the DNSSEC response validation specification [RFC4035]. This sentinel mechanism makes use of 2 special labels: - "kskroll-sentinel-is-ta-<tag-index>. - "kskroll-sentinel-not-ta-<tag-index>. <tag-index> is: 4 hexadecimal digits encoding number in range <0,2^16-1> + TODO: ABNF, zero padded from the left These labels trigger special processing in the resolver as specified bellow. Labels containing "is-ta" and "not-ta" are used to answer questions "Is (or is not, respectivaly) this the key tag a trust anchor which the validating DNS resolver is currently trusting?" Processing of both labels has the very same preconditions for both labels and differs only in last step. 3.1. Preconditions All following conditions must be met to trigger special processing inside resolver code: a) DNS response for particular query is DNSSEC validated and result of validation is SECURE b) QTYPE is A or AAAA // TODO: what about QCLASS? Maybe we can ignore it as DNSSEC is (I believe) class independent ... // TODO: OPCODE == QUERY ? It would not hurt to specify it explicitly. c) leftmost label must be one of "kskroll-sentinel-is-ta-<tag-index>. // TODO: Clarify if it is okay to alter responses if: - QNAME owner holds CNAME - RCODE != NOERROR If all preconditions are not met, the resolver MUST NOT alter the DNS response. 3.2 Special processing Responses which fullfill all preconditions in section 3.1 are subject of special processing, depending on leftmost label of the QNAME. First, the resolver determines if the numerical value of <tag-index> equals to keytag of a Root Zone Key Signing Key which is currently trusted by the local resolver and is stored in its store of trusted keys. As second step, the resolver alters response depending on meaning of the label and presence of key with given keytag among trusted keys. Two labels and two possible states of the keytag generate four possible combinations summarized in the table: Keytag trusted label type | yes | no -------------------------------------------------------------- is-ta | return original answer | return SERVFAIL not-ta | return SERVFAIL | return original answer // TODO: clear up interaction with caching, CD bit, AD bit, ... I would be happy to work more on this particular section because I've already felt pain while implementing this. Petr Špaček @ CZ.NIC On 21.2.2018 15:03, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > > Title : A Sentinel for Detecting Trusted Keys in DNSSEC > Authors : Geoff Huston > Joao Silva Damas > Warren Kumari > Filename : draft-ietf-dnsop-kskroll-sentinel-02.txt > Pages : 13 > Date : 2018-02-21 > > Abstract: > The DNS Security Extensions (DNSSEC) were developed to provide origin > authentication and integrity protection for DNS data by using digital > signatures. These digital signatures can be verified by building a > chain of trust starting from a trust anchor and proceeding down to a > particular node in the DNS. This document specifies a mechanism that > will allow an end user to determine the trusted key state for the > root key of the resolvers that handle that user's DNS queries. Note > that this method is only applicable for determing which keys are in > the trust store for the root key. > > There is an example / toy implementation of this at http://www.ksk- > test.net . > > [ This document is being collaborated on in Github at: > https://github.com/APNIC-Labs/draft-kskroll-sentinel. The most > recent version of the document, open issues, etc should all be > available here. The authors (gratefully) accept pull requests. Text > in square brackets will be removed before publication. ] > > [ NOTE: This version uses the labels "kskroll-sentinel-is-ta-<tag- > index>", "kskroll-sentinel-not-ta-<tag-index>"; older versions of > this document used "_is-ta-<tag-index>", "_not-ta-<tag-index>". ] > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-02 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-kskroll-sentinel-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-kskroll-sentinel-02
- [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sent… internet-drafts
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-… Petr Špaček