On Sun, May 5, 2013 at 6:46 PM, Paul Wouters <[email protected]> wrote: > On Fri, 3 May 2013, Phillip Hallam-Baker wrote: > > 2) The IETF has also proposed two separate mechanisms for asserting a PKI >> policy information. There is DANE and there is HTTP >> certificate pinning. >> > > _service3.example.com URII 10 10 > "https://ws.example.com/**service3/<https://ws.example.com/service3/>pin=foo" >> > > If you trust the DNS for certificate information, then pinning is not > needed. The whole idea behind pinning as I understood it was that people > don't want trust the DNS.
No, the main reason they were doing pinning was that they did not want to be dependent on the vagaries and constraints of the DNS infrastructure or hostage to deployment of DNSSEC. This is a way to merge that approach back into a DNS-centric approach in a clean way. > Note that the discovery parameters could also tell us other things we >> might want to know, whether to look for an A or AAAA record >> for example. >> > > And then you can merge in the HASTLS requirements too :P Yes, those too, in fact they are quite easy, specify HTTPS as the transport. > Special pleading is not going to work. There is never going to be >> consensus that applications should support DANE or TLS cert >> pinning or any one of the dozens of schemes that have been proposed. At >> the moment everyone concentrates on the arguments why >> their pet project should have priority. That is not productive. >> >> If we are going to get anywhere then it has got to stop being a choice >> between extended discovery for DANE vs extended discovery >> for other purposes. We have to have one mechanism that can satisfy every >> requirement to hook a little bit of extra data into the >> discovery process if any of those requirements is going to be satisfied. >> > > I'm unclear what problem you are trying to solve. If you trust the dns, > you don't need pinning. If you don't trust the dns, you cannot trust > your new discovery scheme either? It has nothing to do with whether you trust the DNS or not. Trust is not a binary quality for a start. The issue is how the application discovers that there is useful information to acquire. At present a client that is using extended discovery typically has to perform three parallel queries: A, AAAA, SRV. Adding in DANE makes four and only provides value if the probability of there being a DANE record is high enough to make the effort worthwhile. I am suggesting that instead of making three requests we prune it down to two, the legacy A record request and an additional request that is extensible and so can tell us if we need to make additional requests. -- Website: http://hallambaker.com/
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
