Original message From: Joe Abley On 2 Aug
2019, at 15:30, Bob Harold 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
On 2 Aug 2019, at 15:30, Bob Harold 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
On Fri, Aug 2, 2019 at 2:18 PM Joe Abley wrote:
> On 2 Aug 2019, at 13:24, Witold Krecicki wrote:
>
> > 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
On 2 Aug 2019, at 13:24, Witold Krecicki wrote:
> 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
> COVERTN - as a replacement
Hello Joe,
W dniu 02.08.2019 o 18:28, Joe Abley pisze:
> Hi Witold,
>
> On 2 Aug 2019, at 10:46, Witold Krecicki 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
> On 31 Jul 2019, at 6:51 am, Dan Mahoney 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
Hi Witold,
On 2 Aug 2019, at 10:46, Witold Krecicki 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
W dniu 02.08.2019 o 16:32, Paul Ebersman pisze:
> 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
>
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
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
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> 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
rharolde> If you are looking at putting it outside the zone, it occurs
rharolde> to me that any of the IPAM solutions have a database where you
rharolde> can attach information to records, zones, IP addresses,
rharolde> etc. Even Active Directory can probably do that.
"Buy a commercial IPAM"
On Tue, Jul 30, 2019 at 4:16 PM Paul Ebersman wrote:
> ebersman> Actually, I think this moves your goal nicely. If we could
> ebersman> have things marked as "not zone data, sensitive" and dealt
> ebersman> with only over a covert channel after various auth/acl checks
> ebersman> are done, it
ebersman> Actually, I think this moves your goal nicely. If we could
ebersman> have things marked as "not zone data, sensitive" and dealt
ebersman> with only over a covert channel after various auth/acl checks
ebersman> are done, it would be easy enough to have metadata that won't
ebersman> leak.
On Tue, 30 Jul 2019, Paul Ebersman wrote:
> I was also one of those folks that put things in txt zone files for
> years. My whole IP address management was comments in the in-addr.arpa
> zones. While I went to dynamic zones to make DNSSEC easy and lost that,
> I still see value in things that
I was also one of those folks that put things in txt zone files for
years. My whole IP address management was comments in the in-addr.arpa
zones. While I went to dynamic zones to make DNSSEC easy and lost that,
I still see value in things that should be attachable to a zone but not
zone data and
On Thu, 25 Jul 2019, Paul Ebersman wrote:
> olafur> My suggestion is to take a step back and say we have outgrown
> olafur> AXFR and we need better mechanism to sync various servers.
>
> olafur> Lets start work on a new "SYNC Name servers" protocol that can
> olafur> meet modern requirements
olafur> My suggestion is to take a step back and say we have outgrown
olafur> AXFR and we need better mechanism to sync various servers.
olafur> Lets start work on a new "SYNC Name servers" protocol that can
olafur> meet modern requirements
paulw> +1
+1.
I think we're allowed to replace
> Am 25.07.2019 um 13:25 schrieb Ólafur Guðmundsson
> :
>
> I think all of this makes sense, what does not make sense is to stuff this
> into old "AXFR/IXFR" semantics.
> The draft is already changing how "upstream" deals with "downstream" in this
> proposal.
> My suggestion is to take a
On Thu, Jul 25, 2019 at 01:25:52PM -0400, Ólafur Guðmundsson wrote:
> Dan,
> I think all of this makes sense, what does not make sense is to stuff this
> into old "AXFR/IXFR" semantics.
> The draft is already changing how "upstream" deals with "downstream" in
> this proposal.
> My suggestion is to
On Thu, 25 Jul 2019, Ólafur Guðmundsson wrote:
I think all of this makes sense, what does not make sense is to stuff this into old
"AXFR/IXFR" semantics.
The draft is already changing how "upstream" deals with "downstream" in this
proposal.
My suggestion is to take a step back and say we
On Mon, Jul 22, 2019 at 2:00 PM Dan Mahoney wrote:
> After a hallway conversation with Evan yesterday, I wanted to clarify a
> few things that I came across when working on this. Point one is the
> use-case of NOTE. Point two is an argument for the general usefulness of
> a COVERT record.
>
>
Both docs in this set should say something more about authenticity and
integrity, particularly since DNSSEC cannot be used to establish the
same. (The security considerations sections mention confidentiality.
Authenticity and integrity are likely important for most use cases.)
On the whole,
On Mon, 22 Jul 2019 at 14:00, Dan Mahoney wrote:
> On NOTE:
>
> Moving to the DNS-vendor standard answers of "just use DDNS" or "put it in
> an IPAM" add additional complexity, and additional attack surfaces. DNS
> servers have a tenuous relationship with database backends, and I spend
> enough
After a hallway conversation with Evan yesterday, I wanted to clarify a
few things that I came across when working on this. Point one is the
use-case of NOTE. Point two is an argument for the general usefulness of
a COVERT record.
On NOTE:
I am an admin who uses my zone files as a source of
Hi Tony,
On 9 Jul 2019, at 09:24, Tony Finch wrote:
> Joe Abley wrote:
>
>> 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).
>>
Joe Abley wrote:
>
> 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)
W dniu 08.07.2019 o 22:30, Wessels, Duane pisze:
>
>
>> On Jul 8, 2019, at 1:05 PM, Witold Krecicki wrote:
>>
>> W dniu 08.07.2019 o 19:20, Wessels, Duane pisze:
>>
>>> With respect to 2.6. Interaction with ZONEMD, I'd think it should follow
>>> handling of DNSSEC. That is, covert types
W dniu 08.07.2019 o 22:40, jab...@hopcount.ca pisze:
> Hi Witold,
>
> On Jul 8, 2019, at 16:05, Witold Krecicki wrote:
>
> W dniu 08.07.2019 o 19:20, Wessels, Duane pisze:
>
>> One more thing - this feature is intended for operators, not for regular
>> users. We should have more tolerance
Hi Witold,
On Jul 8, 2019, at 16:05, Witold Krecicki wrote:
W dniu 08.07.2019 o 19:20, Wessels, Duane pisze:
> One more thing - this feature is intended for operators, not for regular
> users. We should have more tolerance for shootfooting features there.
I don't have anything extra to add to
> On Jul 8, 2019, at 1:05 PM, Witold Krecicki wrote:
>
> W dniu 08.07.2019 o 19:20, Wessels, Duane pisze:
>
>> With respect to 2.6. Interaction with ZONEMD, I'd think it should follow
>> handling of DNSSEC. That is, covert types should not be included in a zone
>> digest.
>
> As I
> On Jul 6, 2019, at 4:46 PM, Joe Abley wrote:
> TSIG secrets are rarely rolled in practice, in my experience, and
> being able to improve upon that also seems useful.
Very much agreed, whether using this mechanism or other.
-Bill
signature.asc
Description:
W dniu 08.07.2019 o 21:01, Brian Dickson pisze:
> What about using namespace instead of class or rrtype, or perhaps in
> addition to that?
> By making it an in-band thing but out-of-name-space, it makes it a
> little more difficult to achieve self-immolation.
> The namespace could be specified as
W dniu 08.07.2019 o 19:20, Wessels, Duane pisze:
>
>
>> On Jul 8, 2019, at 9:20 AM, Joe Abley wrote:
>>
>>
>> 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
On Mon, Jul 8, 2019 at 11:47 AM Witold Krecicki wrote:
> W dniu 08.07.2019 o 19:20, Wessels, Duane pisze:>> On Jul 8, 2019, at
> 9:20 AM, Joe Abley wrote:
> >>
> >>
> >> As far as this particular idea goes, I mentioned before what had given
> me pause: we're talking about taking a protocol
Class is a bad idea for a few reasons, but principal among them in my
mind is the fact that per section 4.2 of RFC 1034, the concept of zone
is subordinate to the concept of class—even if zone cuts were in the
same places, example. in a new class would still be a distinct zone from
example. in
W dniu 08.07.2019 o 19:20, Wessels, Duane pisze:>> On Jul 8, 2019, at
9:20 AM, Joe Abley wrote:
>>
>>
>> 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
> On Jul 8, 2019, at 9:20 AM, Joe Abley wrote:
>
>
> 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
>
Hey,
On 6 Jul 2019, at 19:59, Witold Krecicki 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,
W dniu 07.07.2019 o 01:46, Joe Abley pisze:
> On Jul 6, 2019, at 19:28, Witold Krecicki wrote:
>
>> Exactly - while the things you mentioned are configuration options that
>> are 'human generated', the ZSK rollover should be, in the ideal case,
>> something that happens automatically, without
On Jul 6, 2019, at 19:28, Witold Krecicki wrote:
> Exactly - while the things you mentioned are configuration options that
> are 'human generated', the ZSK rollover should be, in the ideal case,
> something that happens automatically, without any human intervention.
It wouldn't necessarily be
- Oryginalna wiadomość -
Od: "Joe Abley"
Do: "Witold Krecicki"
DW: dnsop@ietf.org
Wysłane: niedziela, 7 lipiec 2019 1:09:36
Temat: Re: [DNSOP] proposal: Covert in-band zone data
>There's an argument, I suppose, that an out-of-band mechanism to
>exchange me
Hi Witold,
> On Jul 6, 2019, at 19:05, Witold Krecicki wrote:
>
> The primary use case I'm thinking about is to give secondaries the
> ability to do online NSEC signing to provide white lies. Proposed NSEC5
> also requires a method to transfer the private key to the slave.
> And, again - this is
W dniu 07.07.2019 o 00:39, Joe Abley pisze:
> What's the use-case for using the DNS to transfer private key data?All of
> those methods require configuring an external, out-of-band
mechanism to transfer the ZSK - using covert records is something that'd
work 'out of the box'.
The primary use case
On Sat, Jul 06, 2019 at 03:39:53PM -0700, Joe Abley wrote:
> What's the use-case for using the DNS to transfer private key data?
Inline signing, I believe. Witold should be the one to discuss that one,
not me.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
Hi Evan!
On Jul 6, 2019, at 17:30, Evan Hunt wrote:
> More recently, Witold Krecicki had a very similar idea for a mechanism to
> disseminate private key data between primary and secondary servers. We
> talked it over and decided to expand the NOTE record semantics into a
> generic method for
Colleages,
Some years ago, Dan Mahoney and I submitted a draft describing a proposed
mechanism for storing confidential zone comments alongside normal zone
data - a NOTE RR, which would be transferrable from primary to secondary
servers, but not accessible to ordinary DNS queries. It generated
48 matches
Mail list logo
