as usual, billions arithmetic got me. 0.001 * 2,300,000,000 is 2,300,000
so thats a few dodgers stadiums more than I said...
-G
On Tue, Oct 30, 2018 at 10:41 AM George Michaelson <g...@algebras.org> wrote:
>
> There is a tension between assumed privacy ("this is my resolver, what
> I run is my business, how I run it is my business") of entities
> running resolvers, and customers ("this is my DNS query. what I ask is
> my business") and providers of infrastructure ("this is my liability:
> the consequences of not understanding what we are doing expose me to
> high consequence risk")
>
> Some significant players in DNS conversations have been remarkably
> oppositional to instrumenting the protocol.
>
> I think on balance the question "can your resolver survive the KSK
> roll" is not a massive invasion of privacy, is not a huge impost on
> providers of DNS service, does not interfere with implied rights to
> privacy. We should have better knowledge. We should instrument the
> resolver. The protocol. We should not be forced to do ludicrous things
> to find this out, it should be as innate as the telnet capability
> negotiation, or the HTTP client/server capability negotiation. We know
> how to do these things.
>
> I am statist. I do not pretend states don't exist. I am not a
> libertarian, I am not trumpeting DNS as a tool for individual liberty.
> DNS is a useful functional element which now has consequence when it
> doesn't operate correctly.
>
> We've walked a long way into an industry self-regulation outcome which
> I feel is as consequential as 250v or 50hz, both of which are defined
> parameters with variances and tolerances which people in the
> electricty supply industry have to respect, to remain protected by
> public liability insurance. We should consider the public DNS in the
> same light: If we want to avoid opprobrium over mis-steps in operating
> the root of the DNS, we should adopt a rational posture akin to the
> ones in Power, Water, Sewerage, because thats what we are: a public
> utility function. With public utility liability questions.
>
> Rightly or wrongly DNS is a critical service, which has potential for
> wide impact which is not good. It didn't (this time) at scale, in as
> much as nobody has come forward to say it did: The assumption there
> has been *no* damage, or *no* loss of service feels to me wrong. I am
> (as a gambling man) confident it was low, in as much as 2.3b users
> didn't rise up and grab pitchforks. I bet it was big enough (remember,
> 0.001 of 2.3b is 23,000) that you'd fill an auditorium.
>
> Is 1 in 1000 an acceptable damage rate? is 99.999% unaffected ok? Why
> is 98% not ok? or 97%? Where IS the acceptable damage boundary? Who
> gets to say what will be tolerated as loss in the DNS system, for what
> period of time?
>
> If we want to "plan" for rolls, I think we should stop allowing "not
> on my server" to impede DNS protocol design which would provide
> un-ambiguous signal of capability in the field. And "not in my
> protocol" too. If you offer a service like 8.8.8.8 or 9.9.9.9 or
> 1.1.1.1 you should be in a position of community obligation to be
> completely clear what your posture is towards KSK roll, algorithm
> roll. If you can't support it, you should say so. If that means people
> are advised to TURN YOU OFF that needs to be understood.
>
> If we want to perform algorithm roll, get stand-by keys, we should be
> prepared to argue for the changes which make it easier to do these
> things.
>
> -George
> On Tue, Oct 30, 2018 at 10:29 AM Steve Crocker <st...@shinkuro.com> wrote:
> >
> > 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 <jab...@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 <st...@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 <t...@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.hoff...@icann.org>
> >>> Subject: Re: [ksk-rollover] Informal meeting at IETF 103
> >>> To: "ksk-rollo...@icann.org" <ksk-rollo...@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
> >>
> >>
> > _______________________________________________
> > 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
