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

Steve Crocker <steve@shinkuro.com> Tue, 30 October 2018 00:29 UTC

Return-Path: <steve@shinkuro.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 738D3131001 for <dnsop@ietfa.amsl.com>; Mon, 29 Oct 2018 17:29:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=shinkuro-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 y3DBLzR-Dkhu for <dnsop@ietfa.amsl.com>; Mon, 29 Oct 2018 17:29:27 -0700 (PDT)
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 AC33F127332 for <dnsop@ietf.org>; Mon, 29 Oct 2018 17:29:27 -0700 (PDT)
Received: by mail-yb1-xb29.google.com with SMTP id n140-v6so4293694yba.1 for <dnsop@ietf.org>; Mon, 29 Oct 2018 17:29:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shinkuro-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6HpzSyx0kgOKfwqbMG4Hq6ra2SMaWgCDkP9XY8Dj6Gw=; b=xESsEefGudsxx+WQ8k8g5mS0MV7lEBmccB7Ih6XU130Uy4g0vsfgC1SiCxBkDyZp+R SKzql25T/eTqWgavpWQ+B0JbhLSOS7+xOoMEZGB01fFw9gGQx/r/lvvHrtAIcqcPSFMo l6rMwWueKnu/ZfJo0IfmM0Kkg9nNR7QCirDfOfaWOXuhTPMuoJ1WV2BwJNvNQKu2Hmg7 beFa1f/3w7p5JW7Emgwudq+mNmyT4osTQ4uibqKGUbm8+nmUCCkqgKfo09xWugVTQsFh 1rhRMhBiHEApd9KFkdsS3wjzmlAI6cOMDHiJDp2NdVJ3Jv6dJMgMG3TNApIxyyuoVeoO rMXA==
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=6HpzSyx0kgOKfwqbMG4Hq6ra2SMaWgCDkP9XY8Dj6Gw=; b=FkxHINV2BNaSltGmKdrj5wpoMgfgWI3TOSfuQd+J1tASLk6mYLAUysktMQoe0qMJbk TUH/GTMGPYwglnGYre9GfS8UlojNGzD8tXFYtp1S9LG67TLjMAyS1ShV3+6oWJe4ozbu D9PDt0f9SsdaX0egKBXtNSiqlMKFd1ZH8oTVVvZ9rZco/hl0jJsRPKKumwr4kgMvSnkv cDf2vfiZJNJChSMw1FZSXHwBTr2aI7d711TYY8ZkdyWzC0HcqQAfeqZ00o2mjLhO1gmN AwIGs83thSsvUsX+1YsyZoq533w7DK8fO+AOhn3qpOL28X2qeejh1R1ZwGnjWQb0b6zx Ca/Q==
X-Gm-Message-State: AGRZ1gIJ/f1TQerlA03HbY5kKEenh5K02tSPL5D0mgnObssywQe/Svz5 1fvH8kF4US/VgWTmYizsJIqqUx+QVHeBo1l1fEsNYw==
X-Google-Smtp-Source: AJdET5fd0b/Wh3SMRIMwIRwx80RX2zgO1N3PQx6VgB/HVKHGXGDJvE9nZP0vrVhvFRt4alB9bAzj+Dt/kV1/WVXXOeQ=
X-Received: by 2002:a25:f205:: with SMTP id i5-v6mr15824151ybe.205.1540859366726; Mon, 29 Oct 2018 17:29:26 -0700 (PDT)
MIME-Version: 1.0
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> <A800B089-EC3C-4DEF-95FD-3314ACB311A5@hopcount.ca>
In-Reply-To: <A800B089-EC3C-4DEF-95FD-3314ACB311A5@hopcount.ca>
From: Steve Crocker <steve@shinkuro.com>
Date: Mon, 29 Oct 2018 20:29:15 -0400
Message-ID: <CABf5zvL=VJdzJybYGR6pQFpapS=A9nQuPK-+vR2T7cptRkx5AQ@mail.gmail.com>
To: Joe Abley <jabley@hopcount.ca>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000033f3a10579674798"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/luhBGzA1z99k5nq4wO0wQnOhCMw>
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:29:31 -0000

I had advocated early and frequent rollovers for precisely the reason: keep
doing it until it’s easy, so we’re in strong agreement.

Yes, this one actually went smoothly but there was some tension.  Aside
from any specific improvement, reducing the tension and sense of drama is
mainly what I had in mind.

Thanks,

Steve

On Mon, Oct 29, 2018 at 8:23 PM Joe Abley <jabley@hopcount.ca> wrote:

> 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> 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>
>> Subject: Re: [ksk-rollover] Informal meeting at IETF 103
>> To: "ksk-rollover@icann.org" <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
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>