Re: [DNSOP] dnssec-kskroll-sentinel-06 clarifications

Petr Špaček <petr.spacek@nic.cz> Wed, 28 March 2018 10:46 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 40E7F1205F0 for <dnsop@ietfa.amsl.com>; Wed, 28 Mar 2018 03:46:09 -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 9bub8NFh2GoN for <dnsop@ietfa.amsl.com>; Wed, 28 Mar 2018 03:46:07 -0700 (PDT)
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 BEBCE1200C5 for <dnsop@ietf.org>; Wed, 28 Mar 2018 03:46:06 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:f8f8:f8ff:fe8b:aec7] (unknown [IPv6:2001:1488:fffe:6:f8f8:f8ff:fe8b:aec7]) by mail.nic.cz (Postfix) with ESMTPSA id 55BA362302; Wed, 28 Mar 2018 12:46:04 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1522233964; bh=iYtIUz/Ju8vggve+N8JLdASbmG9i/pYDOUZiFVm1oiE=; h=To:From:Date; b=J/0l82837cFpjoJAN3n2N0AvX4q4TNrLnYS5aJepbQvda1f0otZldrhMdLCb1UtdF 6YwqgX7MpMdeP/yFvCXJolEpmKjMuzyET/0o4pxIgSb3tuV32gjeb08GYxILQm7H9S QaXynkN8NO0ajlDD/D5LoVdHYAF3EdfJksNPQw4M=
To: Geoff Huston <gih@apnic.net>
Cc: dnsop <dnsop@ietf.org>
References: <dfb0182f-fada-c1ea-93fc-4f8c29046725@nic.cz> <F3995DA1-2BDB-4576-B1F7-0EC40EB5D77F@apnic.net>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>
Openpgp: preference=signencrypt
Autocrypt: addr=petr.spacek@nic.cz; keydata= xsFNBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABzSJQZXRyIMWgcGHE jWVrIDxwZXRyLnNwYWNla0BuaWMuY3o+wsF9BBMBCAAnBQJYa4wfAhsDBQkDwmcABQsJCAcC BhUICQoLAgQWAgMBAh4BAheAAAoJEM6N1qGlCiHkjGoP/3fvimzczcaqPM8lgY9fKKcr2DhH 42HF+fXsj0SvPeEoYDuWwIcsTGna6sdmrhCD/mB6eCNivAOcZYDH7j3YDgdFX2xy1sRY0ylF uyfcOT1Qn1xNTglSaf00gUWDgLBQB/USphB9Of6U1ka4gLJpCWKoZ3cLQe09cUpq9HOZYs/g WSNx9UTr06fcO0rtgZpg+IZJN/R2ORhQBwk4n2Dtx5J+Xyoy7ht1Fwz07BWAGJ4P8oJOhsi1 LukDD8ul3+6IeoSbRvyGpP6boegaMwxPR10VgsrYU2t1cK58iRv/xJ3TClb0JBn5aI3Bmh1j mPROrC55tvxRoeRLmxXHzbPZpWdbRjEcf9SEiAGNTgo9C+eXbubeSETWgisfJhZ4ebhkHnfz e+e+hvbaTSoFyMbKeOlfoYCmaDRBgT53i72HIkvO+HrVcmulZytw/yyOHuwObEFVgn3AeORv rb8I1kiv5W4wnZxDslhCeRR+wMGiKhc9ewU/mg3Rqo6GN+8mT0DHnsHuq1lu3WYslfNYkBSo nFcctFD2KXVozrwpn3vWJ4Qt6qu5XS1lDCD5WshZXh7qoISWnnMqsMyBW/R7WyiABeIz4uOg SkRwT2wSUYr+JtBZIjREy2JQDVhjf18DL1Qa7OxSes8YwWSx1pQAzwbfFx0gzRDyIT/39le4 pX430yTQzsFNBFhri/0BEADFp4ZfxSoKTAad0IkFK9CVoZ6XKywYLFNPPhzw++gbvHL2EX7Q qhEsqbsWMYpH4jc/Kq55OYYU/lIcULuD0Y9oDR26XFQou0FeSNnzRGb607U8OFOPQ+ei92Mm 1YPQ33GPj8GqbQpkAp35sfjJ64TH/EQY38RN33jsHRkhwtWU/6yo+RZs7cFRuihuLl8FuoP0 A5u/x+lNNeIBk8f27LVYrF81NSDDDYjnObCah+QLzGAwGDtjWkBVawpoHWwq58OQSx5piwyO CnFJeFONRcTRgOz239rsEA5LeYfmOGcnNwG6CHoJ5ZdWJw5OV9BoA7UTHG95xVHV5QiEm6q6 igI6wKV2RtFS7Roe0Wt8H7gC41JeqaKTUsGkz6uJraF8mmKyS8E+mSh3djmqdJNHF1pJqKxA xPYA9Y0jPnYWeEH4fPeOR2YvBjztsye9nOv1AuKNu03duzocyU95DfP/lwNJr5SH918Vf1t7 WcJj9dg6J9Jc5LOwg13Qr31TuZijrMdqM7LJKC/0tOkSeXNoMlHJOIqbqm7N414I0HytbENf 7AiyDxNA5TzJKkB0eBPLm2FMQCHLfasJHgbCrQut6nYw3f3Gn3+PDzGEHI9sfQv/mYvO77oR SGw+3Hy1ToxIncIirAyRpa5KdPLklDpADvpfkXjuL6IfZZ0OIWKLSRa/DQARAQABwsFlBBgB CAAPBQJYa4v9AhsMBQkDwmcAAAoJEM6N1qGlCiHkn54P/AgyzrffYzRq6d7vHfFhd8HzHHrU BtOK+5182DME1JX9Aow5Dy9kbfxAfTc4tbCY5EnhoUICbmVAJ5wL5lrGxQPSnulIyF8OmJjc VlGI6zXYvP0VHZ/L8dPcf+RPqhMCPpaxe2+h5XpPxvOkDLlnCrsA4J1bAGW5kpxdGnY4aRrv aKhtGMqgSwSx25l3RnoOROU/hTDV4EHCuTkMRfILmsuNT7It40iL5nyDiJ8o3p1CLjRwUzVn 4r4jE8DXhbWXaKJ0KQZpKiQDVV7qJcJIeBJvZpFfxJ44LxBct9TkC69ROntYhd6M7031DT3P IYW9VyMhLN5dRfzhEdFUc+3AlnoOOKcGwYiCnH2DwDva3ZicOAH8099mWZcwVL/sjKKbJGPo JbdT9C3gSnsoa3uBbsiChRhAno80Jsk/igb4QaMw4PsS3230kfBGkQ/oAPPM0iJ9kn8NXB/9 iBe5cKEUiiYQfSn9x1HyG0sT3/jSYaq3obmBNHJE24w/RKWoPsaKjoyaInAuU5L0cNZ30OWd eWFREIxlajFl2vXb9nCc80/i6PceJySiyJgd5cYEL4hfn/B6RXph9kAJySsqlIZoBhcwneGX mAS0M41jJjuIQdt5pkLhM9XoXjBFMGGtA/CtiicEgitItJfVCxdLG4bZOCrfPmevMGLxpEmB GouQ9dVQ
Organization: CZ.NIC
Message-ID: <88b78907-5275-6408-18d7-6bde28fab963@nic.cz>
Date: Wed, 28 Mar 2018 12:46:04 +0200
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: <F3995DA1-2BDB-4576-B1F7-0EC40EB5D77F@apnic.net>
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/RmazEAPFft0xBDFL1t-evy5lfu0>
Subject: Re: [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: Wed, 28 Mar 2018 10:46:09 -0000

On 28.3.2018 01:18, Geoff Huston wrote:
>> 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?
> 
> I think this is correct Petr - i.e.I agree that it would be clear to add
> a further precondition that the CD bit in the query is _not_ set.
> 
> I was VERY surprised to see the opposite text sneak its way into 
> a pull request, and equally surprised that a co-author of the draft
> approved the request and pushed the -09 version without raising this
> on the mailing list, particularly as it directly contradicts your 
> message here.

Hmm, wait, I think we need to clarify one thing:
Current text in -09 reads:
   o  The DNS response is DNSSEC validated, regardless of whether
      DNSSSEC validation was requested, and result of validation is
      "Secure"

I talked to Paul Hoffman about this in person during IETF 101 hackaton
and the intended meaning of "validation was requested" is "regardless of
DO/AD bit in the original query".

Reason is that stubs often emit queries without AD/DO but we want to
validate and apply this logic _unless_ CD is set.

The text "regardless of whether DNSSSEC validation was requested" was
added to warn other avoid other people repeating my mistake from initial
implementation which relied on AD bit in result (which must be requested
by the querier) instead of Secure rank from validator (which does not
depend on AD/DO).

Hopefully it clarifies the intent, but now we need to rephrase the text
in this bullet point... Proposals?

Petr Špaček  @  CZ.NIC


> 
> The current text in -09 reads: 
> 
>    The DNS response is DNSSEC validated, regardless of whether	
>    DNSSSEC validation was requested, and result of validation is	
>    “Secure"
> 
> I believe this text in the current draft is incorrect and leads to
> the wrong behaviour. The idea is for the resolver to act in a manner 
> that is consistent with the way it would behave in a hypothetical key
> roll scenario - and if the query has the CD bit set the resolver would 
> return the response without this special process.
> 
> 
> Geoff