[DNSOP] dnssec-kskroll-sentinel-06 clarifications

Petr Špaček <petr.spacek@nic.cz> Sun, 18 March 2018 20:44 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 F2424127876 for <dnsop@ietfa.amsl.com>; Sun, 18 Mar 2018 13:44:22 -0700 (PDT)
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 CgxfnMb1jVUI for <dnsop@ietfa.amsl.com>; Sun, 18 Mar 2018 13:44:20 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 581CC120727 for <dnsop@ietf.org>; Sun, 18 Mar 2018 13:44:19 -0700 (PDT)
Received: from [192.168.0.230] (cpc130666-camd16-2-0-cust366.know.cable.virginm.net [82.36.141.111]) by mail.nic.cz (Postfix) with ESMTPSA id 48CE762535 for <dnsop@ietf.org>; Sun, 18 Mar 2018 21:44:17 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1521405857; bh=nogB8l4ysJ2iDHRg8MBQm6UB4ZZqaEfCr4oLomLGoDM=; h=To:From:Date; b=Sz28/WIzqExDEPjoht2A6UThBB7RUp9Fh9v4kOSbP+0Z3n1BVPy+sW4o4aawEi5jT 9dKFHpFm9bxCAy4sg3CnH0yh0zMxOjjnRZSBSfxjcxeVSJl5VO5IlvrtOusj0UIh8+ v7hQgjkRuf4zRhhFYb9nqNYKjAM0aTQ80M1oJL6g=
To: dnsop <dnsop@ietf.org>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <dfb0182f-fada-c1ea-93fc-4f8c29046725@nic.cz>
Date: Sun, 18 Mar 2018 21:44:16 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
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/YFBRsUHtc8ccp-qI9i_xni__06E>
Subject: [DNSOP] dnssec-kskroll-sentinel-06 clarifications
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: Sun, 18 Mar 2018 20:44:23 -0000

Hello dnsop,

here are two (hopefully non-controversial) additions for
dnssec-kskroll-sentinel-06:

https://github.com/APNIC-Labs/draft-kskroll-sentinel/pull/14/commits


1st proposal
============
There might be dumb stubs which ignore RCODE and just look for data in
the ANSWER section, i.e. these would not see a difference between
SERVFAIL and non-SERVFAIL RCODE and skew measurement results.

Right now the draft says "return SERVFAIL" and naive implementation
could keep content of ANSWER section intact /as I naively did in first
iteration/, which is not desirable. Proposal here is to add text below
table at the end of section in 3.2:

               |   Key Tag is trusted    |   Key Tag is not trusted
    ------------------------------------------------------------------
    is-ta      | return original answer  | return SERVFAIL
    not-ta     | return SERVFAIL         | return original answer

++  Instruction "return SERVFAIL" means that the resolver MUST set
RCODE=SERVFAIL (value 2) and MUST empty the ANSWER section of the DNS
response, ignoring all other documents which specify content of the
ANSWER section.



2nd proposal
============
Add caveat that SERVFAIL can get cached (forwarding!), so TA
fixes/update might not be visible immediatelly.

Addition to the end of "Sentinel Test Result Considerations":
+      <t>Please note that SERVFAIL might be cached according to
+      <xref target="RFC2308"/> section 7 for up to 5 minutes
+      and a positive answer for up to its TTL.</t>


3rd proposal
============
We have one more thing which needs more manpower to be verified. Right
now, the section 3.1.  Preconditions is:

>  3.1.  Preconditions
> 
>    All of the following conditions must be met to trigger special
>    processing inside resolver code:
> 
>    o  The DNS response is DNSSEC validated and result of validation is
>       "Secure"
> 
>    o  The QTYPE is either A or AAAA (Query Type value 1 or 28)
> 
>    o  The OPCODE is QUERY
> 
>    o  The leftmost label of the QNAME is either "kskroll-sentinel-is-ta-
>       <key-tag>" or "kskroll-sentinel-not-ta-<key-tag>"
> 
>    If any one of the preconditions is not met, the resolver MUST NOT
>    alter the DNS response based on the mechanism in this document.

and later 5.  Sentinel Test Result Considerations discusses how to
interpret results, including considerations for CD bit handling between
recursor and forwarder (we are not speaking about stubs here!).

The current text in section 5 is written with an assumption that query
with +CD bit cannot result in "Secure" status and thus cannot trigger
sentinel processing, but this depends on implementation.

E.g. Knot Resolver stores RRs in cache along with their validation
status, so if a client(s) send query *without* CD bit, the RRs will be
validated and then stored into cache along with its state, e.g. Secure.
Later, when another client asks the same query but with +CD bit, the RR
will be read from cache and its state will be Secure despite of the CD bit.


Now, if we were literally following the version 06 of this draft, we
would trigger the sentinel processing despite the CD bit because the
state is Secure (as cached from a previous query). I suspect that this
is not what authors of text in section 5 expect ...

To counter this I propose to add another precondition:
- CD bit in the query is not set

IMHO it should solve the problem with implementation-specific cache
behavior.

Does anyone see a problem with this addition? What did I miss?

-- 
Petr Špaček  @  CZ.NIC