Re: [DNSOP] Updated KSK Sentinel document

[Warren Kumari <[e-mail]>]

On Fri, Feb 16, 2018 at 12:35 PM, John Dickinson <[e-mail]> wrote:
> Hi,
>
> I like what this draft is trying to do.
>
> I am a bit concerned about adding a invalid RR in to a otherwise correctly
> signed zone. It suspect that there may be a variation in how validating
> resolvers treat authoritative servers that appear to have sent bogus data.
> Some might retry, retry other auth servers, stop using that server
> altogether etc etc…
>
> I suggest that the example A/AAAA RRs on page 4 be written fully qualified
> so there can be no doubt that this draft does not imply new special names at
> the root (which is what I first thought).

Thank you, that's a good catch -- I've made the names in the
"zonefile" all be fully qualified. The fact that these labels can live
anywhere in the tree was a common souce of confusion, so I should have
caught that earlier.

>
> In the discussion of Charlie’s resolvers I think “from
>    this he knows (see the logic below) that he is using legacy, non-
>    validating resolvers.”
>
> should have the “non-“ removed.

Yup, apologies, that was an unfortunate cut-n-paste error. Fixed, and
I just posted a new version incorporating your and Jinmei's comments.

Review and feedback appreciated,
W

>
> regards
> John
>
>
>
> On 12 Feb 2018, at 20:28, Warren Kumari wrote:
>
>> <author hat only>
>>
>> Hi all,
>>
>> Sorry it has taken so long to get a new version of this document
>> posted - you deserve better.
>>
>> Anyway, we've finally posted an updated version -
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/
>>
>> This version includes a (hopefully easily understood) description of
>> how this would actually be used, and not just "here's a protocol, k,
>> thnx, bye!". I've tried to layout what each party does, and how it all
>> fits together - please let me know if it isn't clear. This section is
>> towards the top of the document - we will likely make it an Appendix
>> before publication.
>>
>> I've also updated it to use the kskroll-sentinel-is-ta-<id> format. It
>> is easy to change again in the future, but this seemed to be what the
>> working group liked. I also updated my demo implementation
>> (http://www.ksk-test.net) to use this naming scheme.
>>
>> This version also clarifies that the test is "Is the Key ID a DNSSEC
>> root KSK?" Originally my view was that it should be "Is there *any*
>> key in the trust store with this keyID?", but after running some
>> numbers I decided that there is a significant chance of false
>> positives.
>>
>> As I mentioned, it took an embarrassingly long time to post the update
>> - please let us know if we missed your comments.
>>
>> W
>> --
>> I don't think the execution is relevant when it was obviously a bad
>> idea in the first place.
>> This is like putting rabid weasels in your pants, and later expressing
>> regret at having chosen those particular rabid weasels and that pair
>> of pants.
>>    ---maf
>>
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>
> John Dickinson
>
> http://sinodun.com
>
> Sinodun Internet Technologies Ltd.
> Magdalen Centre
> Oxford Science Park
> Robert Robinson Avenue
> Oxford OX4 4GA
> U.K.



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf