IETF Logo Mail Archive

Re: [DNSOP] [internet-drafts@ietf.org] New Version Notification for draft-hardaker-dnsop-intentionally-temporary-insec-00.txt

Matthew Pounsett <matt@conundrum.com> Thu, 25 February 2021 21:38 UTC

Return-Path: <matt@conundrum.com>
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 08BB63A0BED for <dnsop@ietfa.amsl.com>; Thu, 25 Feb 2021 13:38:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20150623.gappssmtp.com
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 rxmnMb5vDTt8 for <dnsop@ietfa.amsl.com>; Thu, 25 Feb 2021 13:38:13 -0800 (PST)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 3AE463A0BDC for <dnsop@ietf.org>; Thu, 25 Feb 2021 13:38:13 -0800 (PST)
Received: by mail-lf1-x12e.google.com with SMTP id u4so10827597lfs.0 for <dnsop@ietf.org>; Thu, 25 Feb 2021 13:38:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KZrNRD0DBluGcyFcuZ8VyC1qjbvxLjX31be+B3w269o=; b=BUVva7e5Ly7UKjVel9kdvhXThfNI0xGiEmyQM1zIlXozxJXzGD9lYVgO/YRFoDuyFF S9d5MYFwcWwiCLUUR0ReOU34yLqz0hMDhovrRwO9vC8BBTTdq1sN0JGfXWepIZBdORtb 6zyIlxkxQ2AhDfGjPbH8K2HgDAVz9NgNHxsWjj0cgrrxW7KWNxhK/nWGYWc4sPtqw7Vw iVMiIG9eMns3El0Udtty7PJfVcalKbS3UDRVE+sr/Hfl0oJsv+Pl8q9uTUeA0/HsHNpF pBZ9w/b8OrrSzyUARQEne438/Vcr2KGSSzx6EWbXfSXSn5k+2xfbmUqEX2ja5X8cP024 7fpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KZrNRD0DBluGcyFcuZ8VyC1qjbvxLjX31be+B3w269o=; b=FdzIp5AmHQRaWoZEs5gE+VUuWo15t/VNGJJWzxQ4sR72k1ErUT1EL6k5xDSMQqae7y XWDC4l1MvJEaG4HeJXnr+kcBBoFj6DmktqJExyH1QQZ57lrDseJ0SUMnkOL/BPKwkvYy tk7Y3BIzQthxrwWcFFh51G3jMflhBGRN4CEX3103P1+ApMXrf2BjquCZ6foS6eJowCbU fN9e0gS7O6gylrf2PyfZYMsUpY/GLLcL7LZmKsprP1lDp903Ow/7saq3HG7k3OX7Crsw 5mfjmcg/lCVuLc+I+TS2lhU8ce22OAV7QYJnYudcE7n3fkwdpDUqneb1g9FYsKFiNqWe cCQg==
X-Gm-Message-State: AOAM533WItwXH3Z346LicDSynsUfqEMlysWSajMwO+zEoXV8SaEnWOUD /kNoMRetROkvcp0K9XIfT4Vo+TyakfWNlIAM2UMDdA==
X-Google-Smtp-Source: ABdhPJyYNZ22U+wIg2SO4tnXXXeojB8AV/4/nkQf/fifHBTaEB3OozEB9xFuLLGYD8i6karyeYSlnMmMr8GjVso0GiY=
X-Received: by 2002:ac2:5df3:: with SMTP id z19mr3126258lfq.104.1614289091182; Thu, 25 Feb 2021 13:38:11 -0800 (PST)
MIME-Version: 1.0
References: <yblzgzxceqt.fsf@w7.hardakers.net> <e6cf46e1-b88f-e5c1-d30e-ed8045ec76fe@nic.cz> <CAHbrMsBAZEL7_E8rJ8wWQ17679xJeeHaJkk-POEbELNT55=UOw@mail.gmail.com> <yblpn0o9eck.fsf@w7.hardakers.net> <CAHbrMsDTi6NCVfVr6HqnN6Z3nHo6qkWohkR8YaU1JyEjrYtdOA@mail.gmail.com>
In-Reply-To: <CAHbrMsDTi6NCVfVr6HqnN6Z3nHo6qkWohkR8YaU1JyEjrYtdOA@mail.gmail.com>
From: Matthew Pounsett <matt@conundrum.com>
Date: Thu, 25 Feb 2021 16:38:00 -0500
Message-ID: <CAAiTEH-rHkX+Cg6DHJ2F9iTebd9U839ubqfYM51B3nDZWQ9nFg@mail.gmail.com>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Cc: Wes Hardaker <wjhns1@hardakers.net>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d853c905bc2ff7d3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_l6MaLmqXM9DIzoCA9ubD93fRKE>
Subject: Re: [DNSOP] [internet-drafts@ietf.org] New Version Notification for draft-hardaker-dnsop-intentionally-temporary-insec-00.txt
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: Thu, 25 Feb 2021 21:38:15 -0000

On Thu, 25 Feb 2021 at 14:14, Ben Schwartz <bemasc=
40google.com@dmarc.ietf.org> wrote:

> The most interesting informational element, in my view, would be guidance
> on how to detect buggy implementations that will create this problem.  (Set
> up a test zone and a test resolver and ...?).  I think the best practice is
> probably to migrate to a better implementation before rolling the algorithm.
>

Sometimes the bug is an absent operator on the other end of the transfer.
Or an uncooperative one, which RFC 6781 doesn't really address.  I have a
zone I'm planning a move for where the only way it's going to get done,
without going through a bogus state, is by going through an insecure
state.

I'd be extremely uncomfortable labelling that kind of transfer as a best
practice, but it's operational reality that it's going to happen, and it
probably wouldn't hurt to have a document out there explaining how to do it
the best way possible.  Provided, of course, that it's heavily laden with
caveats pointing to all the more secure procedures documented that should
be ruled out first.

v2.23.0 | Report a Bug | By Email