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

[Witold Krecicki <[e-mail]>]

Hello Joe,

W dniu 02.08.2019 o 18:28, Joe Abley pisze:
> Hi Witold,
> 
> On 2 Aug 2019, at 10:46, Witold Krecicki <[e-mail]> wrote:
> 
>> 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.
> 
> 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".
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 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.
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