On Fri, Feb 5, 2016 at 5:02 AM, John Gilmore <[email protected]> wrote: >> design a solution, 3) deploy the solution. The IETF is (only) step #2. > > Yeah, let's not have the designers talking with the deployers. That can > lead to interoperability and harmony, which IETF is dead set against.
If you want deployment, then you had better talk to the developers in step 0, not after the finished product is published. This working group made sure that the developer community was alienated at an early stage. Their input was ignored and some of the participants made sure that they insulted a couple of key people in the browser world whose support was essential. The industry now has or at least it thinks it has two answers to the problems DANE addresses. They are using HTTP key pinning as their security policy layer and are looking at Lets Encrypt for free certs. If you want to achieve the original objectives of this working group and get them deployed, then work within the framework that the parties whose buy-in you need for deployment have already established. HTTP key pinning does provide some security but it is in band to HTTP which means it can only provide security after first use and there is a big potential for 'shooting yourself in the foot'. The DNS based answer to those problems that is deployable is to take the HTTP key pinning record that they have already defined and support in the browser code and publish that exact text string as a DNS Resource Record. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
