On Wed, May 29, 2013 at 09:06:57AM -0400, Suresh Krishnaswamy wrote:
> 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
a). The inefficiency increases the number of public-key signature
verification operations performed on the peer's chain. Not
generally a big deal, but can be a problem. More importantly
the application callback is now invoked multiple times for the
same chain, and we don't know what state it accumulates, whether
it logs errors, ... so the "contract" between the OpenSSL
library and the application changes.
Another inefficiency is that the matching routine is passed a
DER encoded cert even when the TLSA selector is for a public
key, it then decodes the DER cert, extracts a key and DER
encodes that. This should be handled "upstairs", with the
match routine given the right DER object to (optionally digest)
and compare.
b). Also "2 0 0" fails, because the provided certificate may only
be in DNS and not in the peer's chain. The "0 1 0" and "0 0 0"
cases work only because OpenSSL's verification check during
the handshake (see inefficiency above) augments that chain to
include any missing root CA.
c). Here also all usage 0 cases fail when the TLSA RR specifies
a non-root certificate (see above about augmented chain).
d). Yes, it is best to perform name checks on the leaf cert
with 0/2 comparing against at least the base TLSA domain,
but applications should be able to provide a list of names
(see the Tony Finch SRV draft which specifies two names).
This does not punt name checks to the application and
simplifies the return logic.
> 2. The curl patch is broken with respect to DANE usage 2.
Because the application skips name checks, and for the complex
case of "2 1 0". And usage 0 with a non-root CA TLSA RR.
You could choose to not support "2 1 0" without the matching
certificate in the peer's chain. There is no clear language covering
this in RFC 6698. In Postfix I chose to implement "2 1 0" support
because I expect some servers to get this wrong, and I did not want
to punish them for their ignorance. Since it is possible to make
it work, I did.
If my operational guidance draft gets adopted, perhaps this and
similar issues will be more clear to server operators. It is not
yet clear whether client implementations are obligated to deal with
"2 1 0" without a matching certificate on the wire in the server's
TLS handshake.
> 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.
I may have missed some, your design review (see below) should
uncover these.
> 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.
It is good to have early implementations, that are not yet mature
with respect to field testing, ... I do however believe that design
errors should not be present even at this stage. Field testing
should not be needed to shake out design errors. I found the issues
I reported by reading the code, not by running it. Were the code
in production there would need to be a security advisory. This is
not necessary.
While my comment about more implementations not being progress was
inspired much more by the clearly incomplete design of the Firefox
plugin, which was a college project. I do encourage you do go
through all the use-cases, write down the verification requirements,
then read the source code of OpenSSL's X509_verify_cert() in
crypto/x509/x509_vfy.c.
Having understood how the legacy verification process works, what
errors it detects and reports to the application callback and in
what order, you are ready to design an extension that implements
DANE verification.
- Consider the "2 0 0" and "2 1 0" edge cases, where the full
certificate or public key is provided via DNS and may not appear
on the wire in TLS.
- Consider the "2 [01] [12]" edge cases where the full cert or
key is not in DNS, and also may not be in TLS, document that
server operators must provide the TA key or else verification
fails.
- Consider the "2 1 1" use cases where after trust chain
verification completes, though PKIX verifiction relative
to the existing public CA PKI is not required, name checks
are still required to make the peer has the right certificate
issued by the trust anchor. Compare with "3 1 1" where a TLSA
record match is definitive, and no name checks apply (in fact
the certificate may have an empty sequence for its subject DN).
This has implications for API design. Either the DANE verification
API takes care of name checks (and perhaps also PKIX checks
for 0/1), or it needs to report multiple success states:
- with/without name checks required
- with/without PKIX ckecks with public CA PKI required
Failure with all TLSA RRs unusable is different from failure
with some usable, but none matched (see the SRV draft).
The existing public CA PKI is not compatible with some application
protocols (see my drafts recently posted to this list). A library
implementing DANE should likely support these, in which case it
may need to provide controls (flags, ...) to treat some types of
TLSA RRs as unusable and/or to ignore PKIX requirements by treating
0/1 as 2/3 respectively.
These are all design issues that must be considered before code is
first released to the public. Some early code may be written to
explore the space in aid of fleshing out the design, but code should
not be released until the design is complete.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
