On May 28, 2013, at 3:59 PM, Viktor Dukhovni wrote:
- a number of very useful comments.-
Hi Victor,
I believe that having multiple independent implementations of TLSA validation
code is "a good thing" in that it allows us to flag and fix issues early and
build more confidence in the code we use down the line. So your comments in
that respect are particularly useful.
For the purpose of this list I'll try and summarize the broad problems that
you're flagging with the libval DANE implementation and will attempt to move
the gory details of the implementation to our project mailing list. Feel free
to suggest corrections if I've not captured all the points you were trying to
bring up.
1. There are issues with the usage 2 implementation. Specifically (paraphrasing
what you've said earlier):
a) The code is inefficient
b) It does not handle "IN TLSA 2 1 0" where only the public key is in
DNS, and the chain omits the corresponding TA certificate.
c) if the TLSA record trust anchor is in the middle of the chain, DANE
verification incorrectly fails.
d) There needs to be additional name checks on the leaf cert
2. The curl patch is broken with respect to DANE usage 2.
I wasn't able to tell if you were pointing out any specific issues with the
implementation for the other usage types, but if there are any I'd be happy to
add them to my list.
Thanks!
Suresh
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
