TPAC/2014/api-dane-dns
An application-oriented API for DANE and DNS
Summary: We propose an API for application developers providing simplified access to DNSSEC and DANE, for key discovery and other advanced DNS services, without requiring detailed knowledge of the DNS.
Goals: To introduce the API and gauge interest in a standardization effort
Background material: No prep needed, but if interested, see http://getdnsapi.net/
Proposers: Allison Mankin, Melinda Shore
Minutes:
Melinda provided a short introduction to the API and the rationale for its use.
Melinda: What is the correct forum to pursue this work?
DanD: This appears to be an OS level API. Here at W3C, the browser is the platform, are web applications going to have to access What is the use case for the web applications?
Melinda: This would be used by application developers who wanted to secure their application or manipulate keys.
DanD: Need to build the use case around the web application. Is there interest in the underlying technology, leverage DANE for key discovery? Is there a need to use API
Nick Stenning: No way to use this from the client application. While this API may be alot simpler than existing tools, but it still seems to be complicated. I want to connect to this service on this port but only if my DANE record checks out.
MS: This is still a lot of code, don't have a DANE object, talking about building one here.
NS: Do you want to allow / relieve developers of the cryptographic assertions being made under the hood.
MS: Want to make this as opaque as possible so that it is easy for developers.
MS: We were told yesterday to write up a proposal, does that seem like a reasonable thing to do.
DD: Your use case still doesn't appear to apply to web browser.
NS: Does this need standardization? This seems like a utility library.
BL: It would be nice if the way that you do this for CAs or for DANE would be the same.
NS: I don't see how this would fit in Web App Sec.
BL: What does the Web App Sec group do?
NS: Things that web app developers have to worry about.
MS: We are seeing a lot of mistakes in the area of acquisition and storage of credentials
MS: Web App Sec seems to be interesting
KO: Need to clarify the use cases for web developers.
HA: The application would do one thing when the name is secure and another thing if it isn't secure.
MS: That is the getDNS part, but DANE is different because it returns material that you would subsequently use in your application.
NS: What is the use case where the client side web application would make that decision itself as opposed to the web
HA: Web application developers tend to want access to more information including certificates. So perhaps they don't want this information hidden.
MS: Why do they want access to that information.
HA: WebRTC example of why developers want access to this information.
MS: Does this seem interesting in the abstract? Beyond where to take it here in the
NS: I want a simple DANE aware resolver. So, this is very interesting
MS: IETF has typically not standardized APIs.
MS: Unbound is an NLnet Labs project, and getDNS is a joint project with Verisign and nlnet labs. getDNS is using unbound.
AD: Can you talk more about securing the first hop?
MS: Running over the TLS allows passthrough of intrusive middleboxes and protects the privacy of the queries and responses. John Dickenson draft, will be discussed at the dprive wg @ IETF 91.
Conclusions:
This work is interesting and discussion should continue. Need to document web developer based use cases.
Attendees:
Nick Stenning
Melinda Shore
Karen O'Donoghue
Glenn Deen
Barry Leiba
Dan Druta
Harold Alvestrand
Kevin Fleming
Alex Deacon
Peter Linss
Stefan Hakansson
Dennis Tan Tanaka