IETF Logo Mail Archive

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

Witold Krecicki <wpk@isc.org> Sat, 06 July 2019 23:28 UTC

Return-Path: <wpk@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98541200FE for <dnsop@ietfa.amsl.com>; Sat, 6 Jul 2019 16:28:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qd1aDy6MGMia for <dnsop@ietfa.amsl.com>; Sat, 6 Jul 2019 16:28:07 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 570F51200FD for <dnsop@ietf.org>; Sat, 6 Jul 2019 16:28:07 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 0DB443AB001; Sat, 6 Jul 2019 23:28:07 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D4F15160055; Sat, 6 Jul 2019 23:28:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id AE9C2160068; Sat, 6 Jul 2019 23:28:06 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id y74fuWuUeUdU; Sat, 6 Jul 2019 23:28:06 +0000 (UTC)
Received: from zmail1.isc.org (zmail1.isc.org [149.20.0.12]) by zmx1.isc.org (Postfix) with ESMTP id 7897B160055; Sat, 6 Jul 2019 23:28:06 +0000 (UTC)
Date: Sat, 06 Jul 2019 23:28:05 +0000
From: Witold Krecicki <wpk@isc.org>
To: Joe Abley <jabley@hopcount.ca>
Cc: dnsop@ietf.org
Message-ID: <191886397.1948062.1562455685612.JavaMail.zimbra@isc.org>
In-Reply-To: <CAJhMdTPK3iqg4sF0Kr+jGAXTf2MZ8FAP0DgwQw1kVBHa65wTNA@mail.gmail.com>
References: <20190706213024.GA56650@isc.org> <CAJhMdTMwCiAS+S_j-i3BXPZ=G1zVhAq+YKH07RsDWRgezPhejg@mail.gmail.com> <caa695e7-21e6-9c41-1814-1f4c1d64df7f@isc.org> <CAJhMdTPK3iqg4sF0Kr+jGAXTf2MZ8FAP0DgwQw1kVBHa65wTNA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [149.20.0.17]
X-Mailer: Zimbra 8.6.0_GA_1242 (ZimbraWebClient - GC73 (Linux)/8.6.0_GA_1242)
Thread-Topic: proposal: Covert in-band zone data
Thread-Index: YeDDGw+3YVqwcugh0fsoyaIy25i8Zg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/lI8zGIU7l5DvN9ujsW4XP2tMGyg>
Subject: Re: [DNSOP] proposal: Covert in-band zone data
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Jul 2019 23:28:09 -0000

----- Oryginalna wiadomość -----
Od: "Joe Abley" <jabley@hopcount.ca>
Do: "Witold Krecicki" <wpk@isc.org>
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 metadata is already required to agree things like DNS NOTIFY
>targets, master servers andTSIG shared secrets. Those things already
>need to be exchanged securely, so presumably you're not talking about
>just setup time, but rather over time to manage automated ZSK rolls,
>etc?

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. 

-- 
Witold

v2.23.0 | Report a Bug | By Email