Subject: Re: [DNSOP] proposal: Covert in-band zone data

From: Witold Krecicki <[email-masked]>
Date: Fri, 2 Aug 2019 10:52:08 +0200

W dniu 30.07.2019 o 22:16, Paul Ebersman pisze:
> If what you're arguing for is something that's actually mixed into the
> zone data, how do you handle non-compatible/legacy and avoid leakage?

non-compatible/legacy servers won't know the RRTypes that are covert -
and therefore won't be able to load them from disk.

Witold

---

From: Paul Ebersman <[email-masked]>
Date: Fri, 02 Aug 2019 08:32:47 -0600

ebersman> If what you're arguing for is something that's actually mixed
ebersman> into the zone data, how do you handle non-compatible/legacy
ebersman> and avoid leakage?

wpk> non-compatible/legacy servers won't know the RRTypes that are
wpk> covert - and therefore won't be able to load them from disk.

In a polite/sane implementation, sure. But I have scars from my years at
ISC tech support dealing with very broken implementations not done by
the usual FOSS DNS folks. They might fail to load the zone at all, might
stop loading and serve what they have, only serve what they recognize,
crash, etc.

---

From: Witold Krecicki <[email-masked]>
Date: Fri, 2 Aug 2019 16:46:29 +0200

> stop loading and serve what they have, only serve what they recognize,
They should fail to load the zone as it will contain RRs that it does
not understand. As long as they won't serve covert records to general
public - I don't really care.

Witold

---

From: Joe Abley <[email-masked]>
Date: Fri, 2 Aug 2019 12:28:25 -0400

Hi Witold,

> public - I don't really care.

Standard behaviour is to handle opaque types. You're speculating about the broad range of possibly non-standard behaviour and deciding that anything that is non-standard will exhibit one particular kind of behaviour. I think that's the opposite of what we would normally attribute to "non-standard".

I continue to think that taking a protocol (DNS) and deployed implementations (nameservers) that are designed to answer queries and trying to bolt on a backwards-compatible mechanism for carrying data that is not exposed by queries is just a recipe for data leakage. Any data that is really intended not to be disclosed cannot use a mechanism that is almost guaranteed to leak, which means that this proposed mechanism has no real use case.

I am not in favour of this proposal, which I think is camel abuse.

Joe

---

From: Mark Andrews <[email-masked]>
Date: Sat, 3 Aug 2019 02:53:48 +1000

> On 31 Jul 2019, at 6:51 am, Dan Mahoney <[email-masked]> wrote:
> 
> 
> 
> On Tue, 30 Jul 2019, Paul Ebersman wrote:
> 
>> dmahoney> I'd be fine with this data ONLY living on the master, but
>> dmahoney> having it survive things like named-compilezone or rndc
>> dmahoney> freeze/thaw, or the slew of DDNS updates that things like ACME
>> dmahoney> DNS-01 requires.
>> 
>> dmahoney> Effectively, this would be an internal-only DNS record that
>> dmahoney> had a database representation but NO defined wire-format, so
>> dmahoney> there'd be little chance of snooping over the wire (absent
>> dmahoney> some kind of memory leak in the DNS implementation).
>> 
>> Gotcha. So presumably also only on hidden master if that's the
>> architecture.
>> 
>> And transfer of data with these super-comments would be done by file
>> copy, not any DNS standard method?
>> 
> 
> Correct.  I do also envision a limited use-case for this feature where 
> BIND might also add a note indicating the source/time of a DDNS update.  
> But again, purely for humans, not for any action by the nameserver.
> 
> One possible format might be:
> 
> ;NOTE	foo.bar.	NOTE	"pauls workstation”

I would do it as '$NOTE <name> <text>' rather than as a comment which
gets mapped to “<name> 0 <class> NOTE <text>”.  This formalises the
construct and wont accidentally covert any existing comments that
start with “;NOTE “. 

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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Witold Krecicki <[email-masked]>
Date: Fri, 2 Aug 2019 19:24:38 +0200

Hello Joe,

> Standard behaviour is to handle opaque types. You're speculating about the broad range of possibly non-standard behaviour and deciding that anything that is non-standard will exhibit one particular…
An implementation won't be able to load a covert RR from a masterfile
because it won't understand it's TYPE field - it'd either be a specific
COVERT type (which has to be supported to be loaded) or an opaque
COVERTNNNNN - as a replacement for RFC3597 TYPENNNNN (it's not in the
-00, I talked about it during presentation). Yes, the operator can write
a COVERT type as RFC3597 TYPENNNNN and load it into a server that does
not support COVERT. Operator can also put his private DNSSEC keys into a
TXT records - there always will be a chance of footshooting, no matter
how perfect the standards or implementations.

> I continue to think that taking a protocol (DNS) and deployed implementations (nameservers) that are designed to answer queries and trying to bolt on a backwards-compatible mechanism for carrying d…
We already have records that cannot be directly queried (NSEC5),
implementations don't have any problems with not responding to direct
NSEC5 queries. Thinking this way we should never use DNSSEC (or HTTPS)
because a bug in implementation can cause private keys to leak.

Also, this mechanism is not backwards compatible - a server not
supporting COVERT records won't be able, in any way, to serve a zone
that has COVERT records - it won't be able to load the zone (reasons
stated above), it won't be able to transfer the zone from a
COVERT-supporting primary (because it won't send COVERT-OK EDNS0)
option, I'm thinking about putting a requirement that binary formats
(bind9 mapfile/journal) must also be incompatible with
non-COVERT-supporting versions.

> I am not in favour of this proposal, which I think is camel abuse.
Looking at what's happening recently at DNSOP everyone is abusing
labeling everything they don't like a 'camel abuse', it's getting
dangerously close to being just a pure insult...

Witold

---

From: Joe Abley <[email-masked]>
Date: Fri, 2 Aug 2019 14:18:40 -0400

On 2 Aug 2019, at 13:24, Witold Krecicki <[email-masked]> wrote:

> -00, I talked about it during presentation).

Any implementation that doesn't ascribe special meaning to the range of code-points you designate as covert will treat them as standard opaque types. That's the point I'm trying to make.

Further, loading zone data from a master file is just one (arguably archaic) source of zone data. Anything that is received over the wire in an [AI]XFR or an UPDATE is just a wire-format RR, for example, and there's no useful precedent here for a nameserver having to distinguish between different RRTypes when generating responses. The range of back-ends in use today for provisioning RRSets to a master server is also far greater than "master file", and I don't think it's reasonable to speculate about what any/some/most/all of them might do.

> NSEC5 queries.

I would suggest that any implementation that doesn't support NSEC5 is in fact very likely to respond to queries with QTYPE=NSEC5.

> Thinking this way we should never use DNSSEC (or HTTPS)

Private keys are not published as zone data, which I am suggesting.

> that has COVERT records

I am suggesting that it will be able to serve those records perfectly well. That's the crux of my concern, in fact.=

> dangerously close to being just a pure insult...

I certainly apologise if you took it that way; it was meant to be a shorthand for describing my concerns and definitely not a cheap way to discredit an idea. What I intended to mean by "camel abuse" is as follows:

I think that modifying query-response behaviour with respect to specific code points is expensive, and if it is to be done it needs to come with commensurate benefits. I don't see those benefits in this case, as I have described. For that reason I think the expense is not warranted.

Joe

---

From: Bob Harold <[email-masked]>
Date: Fri, 2 Aug 2019 15:30:17 -0400

On Fri, Aug 2, 2019 at 2:18 PM Joe Abley <[email-masked]> wrote:

> Any implementation that doesn't ascribe special meaning to the range of
> code-points you designate as covert will treat them as standard opaque
> types. That's the point I'm trying to make.
>
> Further, loading zone data from a master file is just one (arguably
> archaic) source of zone data. Anything that is received over the wire in an
> [AI]XFR or an UPDATE is just a wire-format RR, for example, and there's no
> useful precedent here for a nameserver having to distinguish between
> different RRTypes when generating responses. The range of back-ends in use
> today for provisioning RRSets to a master server is also far greater than
> "master file", and I don't think it's reasonable to speculate about what
> any/some/most/all of them might do.
>
> I would suggest that any implementation that doesn't support NSEC5 is in
> fact very likely to respond to queries with QTYPE=NSEC5.
>
> I am suggesting that it will be able to serve those records perfectly
> well. That's the crux of my concern, in fact.=
>
> I certainly apologise if you took it that way; it was meant to be a
> shorthand for describing my concerns and definitely not a cheap way to
> discredit an idea. What I intended to mean by "camel abuse" is as follows:
>
> I think that modifying query-response behaviour with respect to specific
> code points is expensive, and if it is to be done it needs to come with
> commensurate benefits. I don't see those benefits in this case, as I have
> described. For that reason I think the expense is not warranted.
>
>
> Joe
>

I am also concerned about data leaking, and special handling by the server.

I just had what might be a crazy idea.
What if the covert data was encrypted, and could be transferred normally,
but only someone with the key could read it?
It could then be put in a new record or in TXT records.
Requires a tool (script) to read/write it, but no changes to the DNS
servers.
Does that make any sense?

-- 
Bob Harold

---

From: Joe Abley <[email-masked]>
Date: Fri, 2 Aug 2019 16:31:21 -0400

On 2 Aug 2019, at 15:30, Bob Harold <[email-masked]> wrote:

> What if the covert data was encrypted, and could be transferred normally, but only someone with the key could read it?
> Requires a tool (script) to read/write it, but no changes to the DNS servers.

To my eye (such as it is) Olafur is on the right track with this. This is a provisioning problem, not a DNS problem.

I think it makes more sense to consider the zone as just one parameter in a DNS workload; other parameters like master servers, zone-specific configuration, NOTIFY lists, etc are additional parameters. Together they make up a blob of DNS provisioning workload. I think the ability to include RRSet metadata (comments, change history, authorisation, data provenance, whatever) in such a blob is most simply a further deconstruction of the "zone" member of that blob.

I do see the benefits of standardising DNS provisioning in general. I would love to be able to have a standard mechanism to add a blob such as that imagined above to an anycast cloud of authoritative DNS servers, for example, instead of having to jump through provider-specific flaming hoops of tickets and APIs.

Joe

---

From: JW λ John Woodworth <[email-masked]>
Date: Fri, 02 Aug 2019 16:52:31 -0400

-------- Original message --------From: Joe Abley <[email-masked]>On 2 Aug 2019, at 15:30, Bob Harold <[email-masked]> wrote:>> I just had what might be a crazy idea.>> What if the covert data was encrypted, and could be transferred normally, but only someone with the key could read it?>> It could then be put in a new record or in TXT records.>> Requires a tool (script) to read/write it, but no changes to the DNS servers.>> Does that make any sense?> To my eye (such as it is) Olafur is on the right track with this. This is a provisioning > problem, not a DNS problem.> I think it makes more sense to consider the zone as just one parameter in a DNS > workload; other parameters like master servers, zone-specific configuration, > NOTIFY lists, etc are additional parameters. Together they make up a blob > of DNS provisioning workload. I think the ability to include RRSet metadata > (comments, change history, authorisation, data provenance, whatever) in such a blob > is most simply a further deconstruction of the "zone" member of that blob.I had a very similar thought.Recently,  I had an opportunity to set up some rather complex bind views where tsig's were needed to keep private views private while allowing multiple views to be transferred to the same host(s).It works rather well and could easily be rolled into something more general purpose./John> Joe_______________________________________________DNSOP mailing [email-masked]://www.ietf.org/mailman/listinfo/dnsop