On Mon, Mar 11, 2019 at 07:34:57PM -0400, Keith Moore wrote: > On 3/11/19 7:10 PM, Nico Williams wrote: > > Self-service tooling requires fine-grained authz -- it's NOT about > > the application protocol. > > Unless, of course, the application protocol constrains the granularity of > authentication. But I don't think that's the case for DNS update. Authorization presupposes authentication (not necessarily to the RP; perhaps the RP doesn't get to learn the client's identity). If your application doesn't give you a way to authenticate, you have a bigger problem than how to do authorization! > > If someone says "let's put this config data in DNS" and someone responds > > "DNS is too difficult to manage", the answer isn't necessarily "let's > > invent a new protocol". > > Agree in principle. But while authentication granularity isn't really a > problem with DNS update (as far as I know), there are other problems with > DNS update that might best be fixed by protocol tweaks. Separately from > that, there are other reasons why it might be appropriate to consider > migrating to a "DNS next generation" protocol. Arguably this is already > happening whether we want it or not. I agree that DNS Update is not a very good protocol. I would support a replacement. But DNS as a protocol for *reading* configuration? That's another story. DNS may or may not be good for reading configuration for some app, but if one would say it's not good because "DNS is hard to manage", well, that's just because there's no self-service support for DNS management, and anything that would replace it would absolutely need it. It's ironic that there are DNS appliance products out there that do not provide self-service admin interfaces. I've seen customers write proxies of sorts to provide the missing self-service layer! > There are several problems, some of which are interrelated. I am not > insistent that any of them be fixed by protocol changes, though I suspect > that some changes and/or new protocol work would be desirable. I also > suspect that some new tooling is desirable. I also suspect that some > policy changes might be appropriate. And perhaps some operational > recommendations. The IETF doesn't build tooling. Just protocols (and APIs, though some will nay-say that in 3, 2, ...). We should consider building authz protocols -- something a wee bit more generic than OAuth, perhaps -- that provide just the right level of granularity *. * too much granularity can == unmanageable mess. The right level of granularity is for the customer to determine. > There's a danger of trying to boil the ocean. There's also a danger of > thinking that some new tool will solve the problem, and scoping the effort > narrowly in terms of creating that new tool, when the new tool that emerges > years later only has the effect of moving the problem and adding additional > complexity to what's already Pandora's box. Indeed, let's not boil the oceans, but let's not reinvent the wheel and miss the one thing that was critical. > At the moment I'm just trying to wrap my head around the problem, or to put > it another way, to discover what scope for the problem could result in less > overall complexity rather than more. Ah, well, right at this moment I am proposing nothing in particular. Just making an observation that I hope will resonate. I do have proposals in mind, but that can wait. > p.s. agree with your summary of self-service tooling requirements. Recognizing the problem is a good step on the way to making progress. Nico --
