But isn’t that example (below) a new API? ;) Back in the earliest days of my security work I recall reading about “mandatory” versus “discretionary” security. The former was security enforced by a controlling system that was untouchable by the entities involved, the latter the security enforcement could be altered by the entities.
Googling for that, I found these slides (https://wiki.engr.illinois.edu/download/attachments/183272958/mandatory-security-policy.pdf?version=2&modificationDate=1318258701000) on the 4th slide is “MAC vs. DAC.” I include that reference just to help define my terminology. If the question is how to enforce that software is “running secure” in this context, the question is whether you want to let the application developer decide that or take away the option. I can see this being done by specifying (the only tool the IETF has) and the verifying via code reviews/testing that an turn-key (for security) API is used over a specified set of libraries. That’s if I don’t have a tight control loop over the developer community. One one extreme, applications can be left to their own devices to do all they need. I’d argue that over the long haul we will wind up with an unmanageable spectrum of code “doing security” in various not-so-consistent ways. There comes a time when things ought to be tightened up. (Examples, what’s going on in EPP, places where developers have had a decade or two to extend protocols.) I’m not sold on sticking with a current API. Perhaps build a more restrictive API for domain-specific security - based on some current API? On Apr 8, 2014, at 10:10, Joe Abley <[email protected]> wrote: > > On 8 Apr 2014, at 9:54, Petr Spacek <[email protected]> wrote: > >> On 8.4.2014 15:20, Edward Lewis wrote: >>> From the linked message: >> >> Let me quote very first part of the message to put it into context: >>>>>>>>>> People start to disagree when it comes to questions like "Is it >>>>>>>>>> feasible to >>>>>>>>>> rely on a local validating resolver in the near future? How can >>>>>>>>>> applications >>>>>>>>>> detect that a validating resolver is not configured and that DNS >>>>>>>>>> responses >>>>>>>>>> can't be trusted?" >>>>>>>>>> >>>>>>>>>> Aim of the proposal below is to enable applications to stay safe on >>>>>>>>>> systems >>>>>>>>>> without a validating resolver. >> >> In other words, we are looking for a way how to augment current APIs to move >> DNSSEC-related knobs from applications to system-wide level (so you don't >> need to tweak OpenSSH config and Postfix config separately, for instance). > > I think introducing a new API to inform applications as to what security > measures are in place is going to be messy and complex. The better approach > is surely to let applications decide what features they want and specify them > through the same API they use to perform DNS resolution, e.g. > > http://www.vpnc.org/getdns-api/ > > > Joe > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
