Subject: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt

From: [email-masked]
Date: Mon, 13 Nov 2017 18:26:02 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : A Sentinel for Detecting Trusted Keys in DNSSEC
        Authors         : Geoff Huston
                          Joao Silva Damas
                          Warren Kumari
	Filename        : draft-huston-kskroll-sentinel-04.txt
	Pages           : 8
	Date            : 2017-11-13

Abstract:
   The DNS Security Extensions (DNSSEC) were developed to provide origin
   authentication and integrity protection for DNS data by using digital
   signatures.  These digital signatures can be verified by building a
   chain of trust starting from a trust anchor and proceeding down to a
   particular node in the DNS.  This document specifies a mechanism that
   will allow an end user to determine the trusted key state of the
   resolvers that handle the user's DNS queries.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-huston-kskroll-sentinel-04
https://datatracker.ietf.org/doc/html/draft-huston-kskroll-sentinel-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-huston-kskroll-sentinel-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Bob Harold <[email-masked]>
Date: Tue, 14 Nov 2017 11:23:16 -0500

> ftp://ftp.ietf.org/internet-drafts/
Looks like you clarified that "_is-ta-<tag-index>." and
"_not-ta-<tag-index>." are the left-most labels.
Thanks, that's an improvement.

I like the draft.

If I have to add those entries to each zone, I worry that the automated DNS
appliance that I use might not be able to create the broken records
required.  But I am not using DNSSEC yet, so that is a future issue for
me.  Still waiting for more automation (CDSKEY etc) and 'time' to work on
it.

-- 
Bob Harold

---

From: Joe Abley <[email-masked]>
Date: Wed, 15 Nov 2017 09:45:47 +0800

Hi Bob,

On Nov 15, 2017, at 00:23, Bob Harold <[email-masked]> wrote:

required.

Since the implementation of the mechanism requires special handling of
queries whose QNAMEs contain the special labels, I don't see why you would
ever need to add anything to any zone.

The point of this mechanism is to require no administrator action and to be
on by default, I think.

Joe

---

From: Warren Kumari <[email-masked]>
Date: Wed, 15 Nov 2017 14:38:14 +0800

> The point of this mechanism is to require no administrator action and to be

Yup, *you* should not need to create these records, as long as someone
does the testing will work -- e.g if example.com publishes:
_is-ta-4f66.example.com
_not-ta-4f66.example.com
badlysigned.example.com

and you can resolve things in example.com you can do the testing. If
your appliance has not been upgraded to know about this new technique
the result will correctly be "unknown / indeterminate" (Vleg[0])

W

[0]: Vleg: A DNSSEC-Validating resolver that does not include this
      mechanism will respond with an A record response for "_is-ta", an
      A record response for "_not-ta" and SERVFAIL for the invalid name.

>
>
> Joe
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

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

---

From: Bob Harold <[email-masked]>
Date: Fri, 17 Nov 2017 08:11:20 -0500

>       A record response for "_not-ta" and SERVFAIL for the invalid name.

So for resolvers that can reach the public internet, only one publicly
available authoritative server needs to have these special records in one
zone?

Could that be made clearer in the draft?

-- 
Bob Harold