Re: [DNSOP] A conversational description of sentinel.

Ralph Dolmans <ralph@nlnetlabs.nl> Mon, 15 January 2018 14:02 UTC

Return-Path: <ralph@nlnetlabs.nl>
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 A253E12D574 for <dnsop@ietfa.amsl.com>; Mon, 15 Jan 2018 06:02:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.611
X-Spam-Level:
X-Spam-Status: No, score=-5.611 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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=nlnetlabs.nl
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 6N85eovijgUR for <dnsop@ietfa.amsl.com>; Mon, 15 Jan 2018 06:02:46 -0800 (PST)
Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [185.49.140.10]) (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 4BFB912426E for <dnsop@ietf.org>; Mon, 15 Jan 2018 06:02:46 -0800 (PST)
Received: from [IPv6:2a04:b900:0:1:993f:b675:9586:5101] (unknown [IPv6:2a04:b900:0:1:993f:b675:9586:5101]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 5FF3DDDC5 for <dnsop@ietf.org>; Mon, 15 Jan 2018 15:02:44 +0100 (CET)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1516024964; bh=CaWKVet38bkoW/gkZswfhnQuohPkpIhF2e0GkWtJitY=; h=Subject:To:References:From:Date:In-Reply-To; b=vQTUJE66s+IdJBqazXVxyNQRXXNPr1Yn98d2flr08EBCErirT8ciawnPCg4WfE2UF PHDEj7J/w8WX4Qxvj11Go69YUMmbX2ClHH+jqDEKMTVrrzI+yD+Cmze+iQuJlXCecg h/9eweuVKIEGkH1RvuMdK1F27p8vrIb/k7CWk7BQ=
To: dnsop@ietf.org
References: <CAHw9_iKnD4WtTKyof=nm4ChmDZ5mAPqA7a_-m1t_Lauugf4Uow@mail.gmail.com>
From: Ralph Dolmans <ralph@nlnetlabs.nl>
Message-ID: <c0d7753c-db0b-c96a-8a3e-1e27ba9c6cc5@nlnetlabs.nl>
Date: Mon, 15 Jan 2018 15:02:44 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAHw9_iKnD4WtTKyof=nm4ChmDZ5mAPqA7a_-m1t_Lauugf4Uow@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/I4NpF5cIwvpkAyH5n_G9LDZD4ic>
Subject: Re: [DNSOP] A conversational description of sentinel.
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: Mon, 15 Jan 2018 14:02:47 -0000

Hi Warren, all,

On 15-01-18 02:51, Warren Kumari wrote:
> The (new) rules:
> A: If the qname starts with _is-ta, and the included keyid is *NOT* in
> the trust store, the resolver changes the answer to a SERVFAIL
> (otherwise things proceed normally).
> B: If the qname starts with _not-ta and the included keyid *IS* in the
> trust store, the resolver changes the answer to a SERVFAIL (otherwise
> things proceed normally).

It is still not clear to me which trust anchor a validator should use
for the sentinel processing. Is that (1) the root trust anchor with
corresponding keyid, (2) the trust anchor with matching keyid for the
domain that is queried, so the example.com trust anchor in your example,
or (3) any trust anchor from the trust store with a matching keyid?

1. Does not require changes in the root zone and makes it possible for
anyone to create a root KSK test. It also means that this test can not
be used for any non-root trust anchor.
2. Requires changes in the root zone, but makes it possible to test the
trust anchor for any zone.
3. Reduces the usefulness of the data. You know that a trust anchor for
that keyid is configured, but you don't know for which zone. Given the
limited number of keyids this does not sound like a good option. A trust
anchor in the trust store with the keyid of the new root KSK does then
not imply that validation will work after the keyroll.

-- Ralph