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

[George Michaelson <[e-mail]>]

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