Re: [DNSOP] Updated KSK Sentinel document

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

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.

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
> DNSOP@ietf.org
> 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.