Re: [DNSOP] Informal meeting about root KSK futures at IETF 103

Joe Abley <jabley@hopcount.ca> Tue, 30 October 2018 00:23 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 17092131001 for <dnsop@ietfa.amsl.com>; Mon, 29 Oct 2018 17:23:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 BQcVXEDgu3Kz for <dnsop@ietfa.amsl.com>; Mon, 29 Oct 2018 17:23:51 -0700 (PDT)
Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 EDAB6127332 for <dnsop@ietf.org>; Mon, 29 Oct 2018 17:23:50 -0700 (PDT)
Received: by mail-pf1-x432.google.com with SMTP id g21-v6so4862507pfi.7 for <dnsop@ietf.org>; Mon, 29 Oct 2018 17:23:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=NGRI6wqe7tJILIqRozIbOLWcTe4eWkhdBpcqPOrmpVQ=; b=pEqA6gCUYbUWicSVVrzZAtjCk1mhK+Y67D5XF0U3nkbnJSiUsaYjcqH2yVF0gs6v8P tRhJFTeTpzKgQp+ZJmY8MkhpqgMvpH7v/nWn/ODTNtMh8277Zb/YKgWXYm/9n5XgRp5w xQ+nkSGQpij3W3uBXZyK5Uwg+jTC5gDqgTqvo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=NGRI6wqe7tJILIqRozIbOLWcTe4eWkhdBpcqPOrmpVQ=; b=LeO8NHHQPPEm3Aba2euB5ET1Jnrl+juUWa4AcwcpwovvsDvA9fjgd5UFbvKCGgordt nq78WF8PH3F/5flPwYBEOFAKi7IrHuqUQuETNBt6vtSb+Es4BPlvMeAHNmA4eeW7jJHW Um1TnJdJBR3dldFKI+YEzszY9f1eVYUnItDJReRcOk3xLcVRl/8bm2XmIBNJyGz+vFrl IWMXCKUe4AU3qOpzTP4tzjnVWjZm5gQOO8FmOLBkTQkdTyAr/3ZGdi3MRdoImKpgDAoc BkWAMl44ASfPeKrBo2zeDnepBis5qERIauLJivHkbC89q7DQl8+QaG9tWmEjP//LG/0x JZDA==
X-Gm-Message-State: AGRZ1gIJC6tFcbjfX6EW4ZkRVJ48ilyQncyoIBdoJhPxSXgJuJed/WWm +QH0HjiG1WaZjjwpWmnI6DEBnw==
X-Google-Smtp-Source: AJdET5fzkt9Fxk2O8/rYi/sPzCb1+B3m7Vdmawl6gA6vmpGw2VX5Tho5W6AkkwbOy5TQJ9200ALNGQ==
X-Received: by 2002:a63:5102:: with SMTP id f2-v6mr11951816pgb.31.1540859030203; Mon, 29 Oct 2018 17:23:50 -0700 (PDT)
Received: from ?IPv6:2607:f2c0:101:3:a99d:ca3f:abbf:9476? ([2607:f2c0:101:3:a99d:ca3f:abbf:9476]) by smtp.gmail.com with ESMTPSA id k24-v6sm22873161pfi.11.2018.10.29.17.23.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Oct 2018 17:23:48 -0700 (PDT)
From: Joe Abley <jabley@hopcount.ca>
Message-Id: <A800B089-EC3C-4DEF-95FD-3314ACB311A5@hopcount.ca>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D8EE3D19-2542-425C-99B4-64D39A3496AA"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Mon, 29 Oct 2018 20:23:46 -0400
In-Reply-To: <CABf5zv+1XFPWaaX1x=W5pAK7rC4HYQ2OsQ4vvoADgKaQufjmBw@mail.gmail.com>
Cc: dnsop <dnsop@ietf.org>
To: Steve Crocker <steve@shinkuro.com>
References: <00E03DAE-9403-49B2-8489-6F7F35D18534@icann.org> <CAJhMdTP-bh1yeOOCS+08rAMhkgyk6yZa9tpQvZ36rR7N=RoQow@mail.gmail.com> <23511.13515.365128.519464@gro.dd.org> <23511.14092.990015.593983@gro.dd.org> <CABf5zv+1XFPWaaX1x=W5pAK7rC4HYQ2OsQ4vvoADgKaQufjmBw@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/mvJluETdkEv64u4yt8_LCQ4ULo4>
Subject: Re: [DNSOP] Informal meeting about root KSK futures at IETF 103
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: Tue, 30 Oct 2018 00:23:53 -0000

Hi Steve,

There will always be the potential for tension between the desire to perform measurement and the need for privacy. In this case it seems to me that a well-intentioned and competent authority, supported by a well-intentioned and occasionally-coherent community has a plausible and sensible desire to understand the configuration of resolvers. I imagine others might see things differently, however. I suspect that having a clean signal that can be relied upon is going to at least change the extent to which client infrastructure is private.

Your last paragraph caught my eye, though. It could be argued that the rollover that just completed was straightforward, at least from a technical perspective. The delays, uncertainty, concern and unfulfilled doomsaying were the things that made it difficult. (It's easy to load that last sentence so that the concern looks ridiculous given the outcome; I am fully aware that the hyperbole would be the thing that looked ridiculous if things had turned out differently.)

To what extent does a regular and frequent cadence of key rollovers obviate the need for concern? It seems to me that at some point down the road if a key roll breaks someone's network, it's going to be much easier to point the finger at the network operator than at whomever is responsible for rolling the key. Perhaps the way to eliminate the things that made the first rollover hard is just to keep doing it until it's officially easy.


Joe

> On 29 Oct 2018, at 18:46, Steve Crocker <steve@shinkuro.com> wrote:
> 
> I won't be in Bangkok, so I won't be able to participate.  In my view, there were two specific problems that dominated the rollover problem.  The first was the inability to determine the configuration of querying resolver.  The second was the in ability to notify resolver operators if it was evident their software was misconfigured.
> 
> Although these two problems became evident and important during the rollover, they also apply more generally, so if the IETF is going to work on improvements, it would be helpful if the improvements would be useful in the event of other configuration or operational issues.  Ideally, every resolver that issues a query would provide configuration information, perhaps in a controlled fashion, and there should also be a way to notify the resolver operator of operational problems.
> 
> We will need to do more rollovers in the future, driven at least in part by the need to change algorithms.  I would hope we can work toward making these relatively straightforward.
> 
> Thanks,
> 
> Steve
> 
> 
> On Mon, Oct 29, 2018 at 12:36 PM Dave Lawrence <tale@dd.org <mailto:tale@dd.org>> wrote:
> Dave Lawrence writes:
> > Count me as another, for that very reason.  When I first saw Paul's
> > message I thought, "oh that's a shame" but figured it to be fairly
> > set.  If there's flexibility for making the meeting happen earlier in
> > the week, I'd be interested.
> 
> Following up to my own message, since this was further down in my box
> on another list...
> 
> ------- start of forwarded message (RFC 934 encapsulation) -------
> From: Paul Hoffman <paul.hoffman@icann.org <mailto:paul.hoffman@icann.org>>
> Subject: Re: [ksk-rollover] Informal meeting at IETF 103
> To: "ksk-rollover@icann.org <mailto:ksk-rollover@icann.org>" <ksk-rollover@icann.org <mailto:ksk-rollover@icann.org>>
> 
> Based on some requests from folks who are leaving the IETF meeting
> early, I have also reserved a meeting room for 1600-1700 Wednesday
> afternoon (local time), Pagoda Room on the 4th floor.
> 
> And just to emphasize: the purpose of this week's informal gatherings is
> to let folks in the IETF community chat about their ideas in front of
> other IETFers. This is similar to the KSK-related mic lines at the
> DNS-OARC and RIPE meetings a few weeks ago. These IETF side-meetings
> really are just slightly-better-organized hallway discussions. Given the
> wide range of proposals we have already heard, it is good to get a bit
> of face-to-face sharing going early.
> 
> We won't start formal planning about the KSK futures until after the
> rollover process is complete*. When we do, we'll do it in discussion
> environments that are much more inclusive than these informal IETF
> side-meetings or the mic lines at other technical meetings.
> 
> [...]
> ------- end -------
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop