Subject: [DNSOP] TA signal - suggestion to enhance signal

From: Brian Dickson <[email-masked]>
Date: Mon, 13 May 2019 10:17:36 +0700

The original RFC 8145 gives the ability to gather trust anchor signal data.

There are limitations related to inferring either reasons for behavior
observed on the aggregate volumes, or identifying originating
resolvers/forwarders versus upstream resolvers/forwarders (which could
include both NAT and forwarder root causes).

I believe the additional information that would be operationally useful as
well as helpful for being able filter or otherwise drill down within the
collected data.

The extra information I believe would be useful includes software (package
and version), and some unique identifier for each host, plus an identifier
derived from (possibly non-unique due to RFC 1918) host's IP address.

Putting this information underneath the _ta-* label, would allow the
high-level signal (the _ta itself) to be aggregated as easily as currently,
while also enable drilling down and/or aggregating/filtering to address any
PII issues.

Suggestion for software id: whatever software currently puts into
version.bind or equivalent name, in the CH TXT class and type.

Suggestion for host id: some UUID generated either at software install
time, or at software launch time,

Suggestion for IP-based ID: hash of IP, where  IP is "live", so changing
the IP results in change to the hash. This has the added benefit of
validating that the IP address of the incoming _ta query is the originating
system, versus NAT IP (possibly folding multiple hosts onto fewer/different
IP addresses) or forwarders who forward queries for clients.

I believe these will be useful in analyzing the 8145 data, to extract
better signal data, and to filter data that is effectively "noise", and/or
track sources and changes better across event boundaries.

Thoughts?

Brian

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 13 May 2019 04:21:31 +0000

> On May 13, 2019, at 10:17 AM, Brian Dickson <[email-masked]> wrote:
> 
> There are limitations related to inferring either reasons for behavior observed on the aggregate volumes, or identifying originating resolvers/forwarders versus upstream resolvers/forwarders (which could include both NAT and forwarder root causes).
> 
> I believe the additional information that would be operationally useful as well as helpful for being able filter or otherwise drill down within the collected data.
> 
> The extra information I believe would be useful includes software (package and version), and some unique identifier for each host, plus an identifier derived from (possibly non-unique due to RFC 1918) host's IP address.
> 
> Putting this information underneath the _ta-* label, would allow the high-level signal (the _ta itself) to be aggregated as easily as currently, while also enable drilling down and/or aggregating/filtering to address any PII issues.
> 
> Suggestion for software id: whatever software currently puts into version.bind or equivalent name, in the CH TXT class and type.
> 
> Suggestion for host id: some UUID generated either at software install time, or at software launch time,
> 
> Suggestion for IP-based ID: hash of IP, where  IP is "live", so changing the IP results in change to the hash. This has the added benefit of validating that the IP address of the incoming _ta query is the originating system, versus NAT IP (possibly folding multiple hosts onto fewer/different IP addresses) or forwarders who forward queries for clients. 
> 
> I believe these will be useful in analyzing the 8145 data, to extract better signal data, and to filter data that is effectively "noise", and/or track sources and changes better across event boundaries.
> 
> Thoughts?

Hi Brian,

Thanks for the suggestions.  I think the first discussion needs to be whether there is support for better signals at the expense of possibly less privacy.  My sense of the way things are today is that "privacy is king."  

DW

---

From: Brian Dickson <[email-masked]>
Date: Mon, 13 May 2019 11:30:33 +0700

On Mon, May 13, 2019 at 11:21 AM Wessels, Duane <[email-masked]>
wrote:

> > I believe the additional information that would be operationally useful
> as well as helpful for being able filter or otherwise drill down within the
> collected data.
> >
> > The extra information I believe would be useful includes software
> (package and version), and some unique identifier for each host, plus an
> identifier derived from (possibly non-unique due to RFC 1918) host's IP
> address.
> >
> Thanks for the suggestions.  I think the first discussion needs to be
> whether there is support for better signals at the expense of possibly less
> privacy.  My sense of the way things are today is that "privacy is king."
>

Good point; probably configurable and either opt-out or opt-in, possibly
with defaults selected by e.g. whoever is "packaging" a particular open
source project (where philosophies on privacy may differ significantly).

Brian

---

From: George Michaelson <[email-masked]>
Date: Mon, 13 May 2019 11:31:28 +0700

> Thanks for the suggestions.  I think the first discussion needs to be whether there is support for better signals at the expense of possibly less privacy.  My sense of the way things are today is t…

I think this is an accurate characterisation of the situation. But
having said that, I think the lack of capabilities signalling in DNS,
compared to say SMTP or HTTP is a huge problem, and since we have it
in those protocols, I feel we have a basis to suggest there is not a
blanket ban on this kind of thing in the model.

Because of the massive lack of information about elements of the
system, the lack of signalling is actually causing a problem. Thats
distinct from the hypothetical privacy breach which I acknowledge is a
fear, but its a fear which has to be balanced by the problem space
we're in.

-G

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 13 May 2019 09:12:39 +0200

> Thoughts?

There's the hiding problem due to aggressive caching, especially when
forwarding to a resolver that does aggressive caching (1.1.1.1 is
well-known but there are more).
https://tools.ietf.org/html/rfc8145#section-5.3.1
If the label was extended to a large number of possible values, the
workaround suggested in the RFC or wildcard wouldn't help.  Moving the
labels to an unsigned zone would solve that.  So far there's been no
work-around deployed; I don't know why.

I agree privacy concerns might be a significant problem.  I'm not even
sure about usefulness of information like host UUID.  I can't see how it
helps with estimation of amount of internet population affected by a
problem - or with finding what SW/configuration caused it.

Another fundamental issue is, I believe, that in short term similar
signalling will only show information from better-maintained instances
that are up to date and thus much less interesting.  It _might_ get more
useful after several years, but that would need careful
planning/anticipation wrt. what information we expect to be useful in
more distant future.

--Vladimir