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

Joe Abley <jabley@hopcount.ca> Sat, 06 July 2019 23:46 UTC

Return-Path: <jabley@hopcount.ca>
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 86134120105 for <dnsop@ietfa.amsl.com>; Sat, 6 Jul 2019 16:46:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 8Ck1SvPoCEpu for <dnsop@ietfa.amsl.com>; Sat, 6 Jul 2019 16:46:40 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC19F1200FD for <dnsop@ietf.org>; Sat, 6 Jul 2019 16:46:39 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id 16so12423494ljv.10 for <dnsop@ietf.org>; Sat, 06 Jul 2019 16:46:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc; bh=a+jgklHSC6DthnAJFRJiUd1+JNHdwfHVFNLk9tWeU6k=; b=Zvi3ztZATHepCpdBX88RRI734nqRGPq2T1hMsIzzokR2Soo3jg+MP7bYl4IUbpIuBf r/EMStA821Q3cLcfWFzK2DjNAMBIXCQ+mFVZtZZIegfGf+aSQjI5kG7zJy9JT+2OXjwO Zqyz3oCsOxs67VLDNh/vpMPll6aTFxc3CmOb0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc; bh=a+jgklHSC6DthnAJFRJiUd1+JNHdwfHVFNLk9tWeU6k=; b=Vp1mHrruZhmRyjO88yzThw18xHiJlyW4yXTMP6hMXiwGPsM9T+bUuBOxb/psMhFNsg 0P+4HIa98uRWzin0sPoypY4lRNaNJB7RL7KmelMwTV/1Knga0Er5xvPxylWuSMPgNqyE Oay9HS74yr8lq0feuN13PtB4JA6y/1vhwW1l7y3NWItr2HFbcqeNFyiLw1q2zA/ZCged Okoo6mYyBfprm5205ZgnWw3WsD5mnvi3TXeyeli+53ZKhYkUcvtKVjQZAfYDI2aSZ5nc jAXY46PM2IQIZqcaAZGJXPoHbW9eS1pQflFNpFoi6mVb3pp/pOYmeEYbc9zvWyzzf9OC MGAQ==
X-Gm-Message-State: APjAAAW3JdZpuhHVgzjmvCB0dF8DqDK3ggreUNiLottEXJl3deaWa7FI H58AKYJc/AulMHmn89YEVjVRnwJOQJFBju0YIT+/uA==
X-Google-Smtp-Source: APXvYqyFaFS0dp12aB93+hkUi+d783hr/1i8+6OSwOjEEVM8xxea59Y8svfEgqeWeVBIruylspgiDSvfbT1bbGOpgOU=
X-Received: by 2002:a2e:868e:: with SMTP id l14mr5983474lji.16.1562456797970; Sat, 06 Jul 2019 16:46:37 -0700 (PDT)
Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Sat, 6 Jul 2019 16:46:36 -0700
From: Joe Abley <jabley@hopcount.ca>
Mime-Version: 1.0 (1.0)
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> <191886397.1948062.1562455685612.JavaMail.zimbra@isc.org>
In-Reply-To: <191886397.1948062.1562455685612.JavaMail.zimbra@isc.org>
Date: Sat, 06 Jul 2019 16:46:36 -0700
Message-ID: <CAJhMdTNvO=TjNUV=6wHwLJB_c+tqwk4zY24jGbi5a0SqdSUsag@mail.gmail.com>
To: Witold Krecicki <wpk@isc.org>
Cc: dnsop@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/BOyEkVQMXFy3IuYmXp1EigX-dD0>
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:46:42 -0000

On Jul 6, 2019, at 19:28, Witold Krecicki <wpk@isc.org> 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 harmful to be able to update those other
things automatically, too. Things like master servers and NOTIFY
targets perhaps change less frequently or predictably than a ZSK, but
in times of emergency all could benefit from a well-designed,
automated and secure mechanism to handle changes.

TSIG secrets are rarely rolled in practice, in my experience, and
being able to improve upon that also seems useful.

I still wonder whether what you're proposing really only solves one of
a wider set of problems, and whether doing it in the DNS really makes
sense. Perhaps a standardised, out-of-band provisioning protocol would
be better.

We might have a need to exchange some other kind of metadata between
authoritative servers for a zone in the future, eg relating to secure
transports or privacy. The idea of being able to provide a general
solution to solve future such problems seems attractive.

None of this is commentary directly about your draft, of course.


Joe