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

[Geoff Huston]

>> 
>> 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”
>> 

After discussing this with Warren and Joao I’d like to propose a slightly 
different wording to the WG. The proposed wording is:


All of the following conditions must be met to trigger special
processing inside resolver code:

The DNS response is DNSSEC validated

The result of validation is "Secure"

The AD bit is to be set in the response

The QTYPE is either A or  (Query Type value 1 or 28)

The OPCODE is QUERY

The leftmost label of the original QNAME (the name sent in the
Question Section in the orignal query) is either
"root-key-sentinel-is-ta-" or
"root-key-sentinel-not-ta-"

If any one of the preconditions is not met, the resolver MUST NOT
alter the DNS response based on the mechanism in this document


What was concerning me was that the wording in -09 could be mis-interpreted to 
be subtly altering the preconditions for a resolver to perform validation, and 
that's best left to the mainstream DNSSEC specification documents. If there are 
any lingering uncertainties as to when and why a resolver performs DNSSEC 
validation and communicates the outcome in a response, I think that they are 
best resolved in a focussed discussion on the preconditions for DNSSEC 
validation rather than obliquely in this sentinel draft. Hence the proposed 
text above, that simply says that the AD bit is set in the response. 

The other change I’m proposing is one of consistency - the -09 text had 
proposed two conditions in one sentence than enumerated a further three 
conditions. I felt it was more consistent to explicitly enumerate all 
conditions.

Are there any objections from the WG to integrating this change and pushing out 
a -10 version of this draft?

regards,

   Geoff



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Petr Špaček]

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  (Query Type value 1 or 28)
>>>
>>>   o  The OPCODE is QUERY
>>>
>>>   o  The leftmost label of the QNAME is either "kskroll-sentinel-is-ta-
>>>  " or "kskroll-sentinel-not-ta-"
>>>
>>>   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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Geoff Huston]

> 
> 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.
> 
> 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.
> 

My sincere apologies for the intemperate tone of this post, and to Paul and 
Warren
here. I managed to choose a form of expression that conveyed a far more strident
and aggressive tone than I intended, and I sincerely did not intend to cause
offence here. In any case I do apologise for this, and I'll attempt to be far
more prudent in future with my postings to this list.


Geoff

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Geoff Huston]

> 
> 
> 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  (Query Type value 1 or 28)
>> 
>>   o  The OPCODE is QUERY
>> 
>>   o  The leftmost label of the QNAME is either "kskroll-sentinel-is-ta-
>>  " or "kskroll-sentinel-not-ta-"
>> 
>>   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.

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









___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

> On 20 Mar 2018, at 3:10 am, Vladimír Čunát  wrote:
> 
> On 03/18/2018 09:44 PM, Petr Špaček wrote:
>> 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.
> 
> I just want to note that this situation of answering +cd queries by
> validated cached RRs isn't very implementation-specific.  One way to
> come to this: it seems generally desirable to have aggressive caching
> (rfc8198) on forwarders, due to serving as a cache shared by multiple
> resolvers, and validating resolvers tend to use +cd to query the
> forwarders (rfc4035#section-3.2.2).

You can’t assume whether CD will be 1 or 0 when the client is validating.
Both types of queries are useful.  The mentioned section just fails to
discuss the CD=0 case.

> --Vladimir
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vladimír Čunát]

On 03/18/2018 09:44 PM, Petr Špaček wrote:
> 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.

I just want to note that this situation of answering +cd queries by
validated cached RRs isn't very implementation-specific.  One way to
come to this: it seems generally desirable to have aggressive caching
(rfc8198) on forwarders, due to serving as a cache shared by multiple
resolvers, and validating resolvers tend to use +cd to query the
forwarders (rfc4035#section-3.2.2).

--Vladimir

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] dnssec-kskroll-sentinel-06 clarifications

[Petr Špaček]

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":
+  Please note that SERVFAIL might be cached according to
+   section 7 for up to 5 minutes
+  and a positive answer for up to its TTL.


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  (Query Type value 1 or 28)
> 
>o  The OPCODE is QUERY
> 
>o  The leftmost label of the QNAME is either "kskroll-sentinel-is-ta-
>   " or "kskroll-sentinel-not-ta-"
> 
>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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop