Dear Viktor, On 11.12.2014 16:05, Viktor Dukhovni wrote: > On Thu, Dec 11, 2014 at 11:51:56AM +0100, Jonas Wielicki wrote: > >> I recently started working on a python3 library[1] to support >> the implementation of DANE in python3 based applications. I am >> looking for some support in form of a second or third pair of >> eyes. As this is a security sensitive topic, I would be glad if >> someone took the time to look over the approx. 600 lines of >> python code or the user interface documentation. > > Here's my advice. I fully encourage you to experiment with this > code, as a productive learning exercise. However, please *do not* > document this as something other than experimental code that you > used to develop your understanding of the various technologies. > > Unfortunately, in the DANE space, we have too many "toy" libraries > that are wrong or incomplete, and too few that are correct and > comprehensive, and will be maintained in the long term.
I understand your concerns and I have added a note to the README and a huge red warning to the autogenerated docs. > A more valuable contribution would be Python code that locates the > right validated TLSA records for a host:port combination that > deals with CNAME expansion and all the requisite DNS error handling > per the OPs draft. For extra points, code that does this > indirectly via SRV or MX records, and produces also the correct set > of "reference identifiers" that go along with the TLSA records for > handling certificate usages 0, 1 and 2. This should also handle > conversion of IDNA hostnames to A-label form for DNS lookups and > certificate reference identifier construction. I agree that this indeed is also a field of problem. However, I currently don’t dare to implement a DNSSEC validating resolver, which would be required for this task (or, again, offload the burden of ensuring such a resolver is present to the user, which is generally error-prone). There is DNSPython, which has some DNSSEC utilities, but as far as I know does not provide validation support. Thank you for giving me the hint to the draft though. I did not know that it existed and it provides valuable insights on the workings of DANE. > * Usages PKIX-TA(0) and PKIX-EE(1) never accept chains that would > fail PKIX validation in the absence of DANE (including name > checks). These only "constrain" which chains that pass PKIX > validation should be accepted. Thank you, that answers my question. > Great care must be exercised here, for example, after PKIX > validation succeeds, a naive request to OpenSSL for the peer's > chain returns the list of wire certificates, not the validated > chain. But I assume that one can obtain the actually validated chain using the verify_callback mechanism provided by OpenSSL? > Additional complications arise due to cross-signing, that make it > difficult to validate a PKIX chain constructed in isolation from > the DANE records. Such a chain might use a trust-anchor "below" > the one that matches the DANE records. I read about that in the draft. I think this is unfortunate, as it really requires to meld the support into the PKIX validating library, something I hoped could be avoided (or, alternatively, validate yourself, as you appearantly did in the postfix DANE code). > * Usage DANE-TA(2) is the most difficult to support, and "toy" > implementations neglect to perform chain construction and integrity > checks or perform name checks, apply name constraints, depth > constraints, handle IDNA conversion of hostnames, ... I wonder whether adding certificates provided by DANE-TA records (assuming we have a Cert+Full record) to the trusted store of the SSL implementation (only for that particular connection) and check whether these have been used after the fact would be sufficient?. thank you for your input, Jonas Wielicki _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
