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

[Joe Abley <[e-mail]>]

Hey,

On 6 Jul 2019, at 19:59, Witold Krecicki <[e-mail]> wrote:

> But why put it out-of-band when it can be in-band?

I don't think there's a good general answer to this. Sometimes in-band signalling is good; other times out-of-band signalling has proved to be safer. I'm talking very generally, here, not directly about your proposal.

As far as this particular idea goes, I mentioned before what had given me pause: we're talking about taking a protocol where every RRSet in a zone to date has been public and is made available in DNS responses. Any server that doesn't implement this new mechanism would presumably treat the new covert RRTypes as they would any other unknown/opaque type and make the data public.

There is hence an operational risk that data will leak (e.g. by configuration changes, software downgrades that are pragmatic necessities, side systems that publish zone data in ways other than the DNS).

By keeping data that is already exchanged over a (manual) out-of-band channel separate, and not packaging them up with zone data, the existing segregation of private vs. public is preserved and the task is simply to automate a process that is currently manual.

This might sound like a very high-level concern, but I suspect there are ramifications of changing the security model of the data published in a zone that extend beyond the operation to the wider architecture, e.g. what to do with PII that is published in a covert record, and what extra work results from the changed risk profile of that data? In a segmented security architecture, what are the implications of sensitive material being mixed with public information?


Joe