[Cryptography] End-to-End Protocols and Wasp Nests

Viktor Dukhovni cryptography at dukhovni.org
Mon Mar 10 09:40:18 EDT 2014

On Sun, Mar 09, 2014 at 10:58:20PM -0700, Tom Mitchell wrote:

> A problem with combinatorial testing is the permutations get
> too numerous very quickly.  Testing cycles move from hours
> to weeks.

What I had in mind was a set of TLS servers which exhibit a number
of important edge cases with respect DANE TLSA chain validation,
but these should, if possible, also cover TLS protocol tests.

An example anomaly is "IN TLSA 2 0 1 {TA digest}" matching a CA
presented by the server, where the server's chain is disconnected.

I've seen implementations of DANE verifiers that accept any "chain"
which contains a matching usage 2 (private CA) trust anchor, without
checking that a path can be built from this trust anchor to the
leaf certificate.  This is just a feature test, there is no
combinatorial explosion.

We can add a test to make sure that DHE and ECDHE server key exchange
messages are properly validated, but I see little reason to test
combinatorics of this second anomaly with the disconnected server
chain anomaly.  Thus we'd have two tests so far, not 4.

Similarly if one tests for correct enforcement of path length
constraints or name constraints, it seems unlikely that this would
be dependent on either of the previous tests.  (Though one should
test enforcement of path length constraints for each of the four
DANE certificate usages).

Many of the important cases that implementations should reject can
be tested in isolation, and are the least well tested cases in
practice.  Much testing focuses on accepting valid inputs, where
combinatorial testing is more likely to be needed.

If the test-suite becomes too expensive to run on every build, it
can be used only for pre-release builds...


More information about the cryptography mailing list