BIND 10 #781: Define cryptographic API

[BIND 10 Development]

#781: Define cryptographic API
-------------------------------------+-------------------------------------
                 Reporter:  stephen  |                Owner:  jinmei
                     Type:  task     |               Status:  reviewing
                 Priority:  blocker  |            Milestone:
                Component:           |  Sprint-20110419
  Unclassified                       |           Resolution:
                 Keywords:           |            Sensitive:  0
Estimated Number of Hours:  6.0      |  Add Hours to Ticket:  0
                Billable?:  1        |          Total Hours:  0
                Internal?:  0        |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => jinmei


Comment:

 Replying to [comment:8 jinmei]:
 > Some initial feedback:
 >
 > First, I made a few trivial editorial cleanups and pushed them to the
 > branch (commit 4f1d8d0).
 >

 Thanks, I noticed I forgot to push the last 3 commits :/ (two were also
 editorial things and documentation, one added python support for the new
 functions)

 > Second, it doesn't compile from the scratch because crypto_unittests
 > relies on some libdns++ header files (explicitly/implicitly), some of
 > which are generated at compile time of libdns++.  (specifically,
 > rrclass.h)
 >

 Changed order in lib/makefile, but see also below I guess.

 > This particular problem could be solved in some way, but I think it's
 > actually one aspect of a bigger design discussion: does it make sense
 > to rely on DNS specific notions from the crypto (interface) API?  More
 > specifically, does it make sense to use TSIGKey and OutputBuffer also
 > as input parameters to signHMAC()/verifyHMAC()?
 >

 I was wondering if TSIGKey shouldn't be in libcrypto itself. Since it
 would still be dependent on Name I chose to leave it where it was.

 > Personally, I'd decouple independent things as much as possible.  In
 > this specific case it seems that input/result data can simply be
 > opaque binary data and can be represented as (e.g.) a pair of a
 > pointer and length, and/or a std vector object.  Representing a key is
 > not that trivial because we have to think about how to represent the
 > algorithm, but if we want to keep the crypto API separate from
 > libdns++, I think it makes more sense to introduce a generic
 > representation (i.e. not in the form of dns::Name) of hash algorithms,
 > have the user of the API (e.g. DNS message signer/verifier) convert
 > the algorithm DNS name to the generic representation.  Or, if our
 > intent is to limit the usage of the crypto API to DNS related
 > purposes, it would make more sense to define the API under libdns++.
 >

 If we change the methods to not take TSIGKey, we do need to pass it nearly
 all information about it; it would make sense to make a class for that,
 which I originally had, but then I discovered we already had
 isc::dns::TSIGKey, and making two separate classes to represent the same
 object doesn't make much sense to me (and two lists of algorithms (three
 if you count the backend-lib-specific one too), etc).

 I also considered moving TSIGKey to libcrypto, but as i said above, it
 would still have the link to isc::dns::Name.

 Making the crypto api fully dns independent seems to me to be too
 abstract, unless we need it for other uses for it than dns-related things.
 The dns-related things we do need would then need yet another level of
 abstraction (and a dependency the other way around, since I expect that
 one to live in libdns++), and another conversion step.

 If we don't need it for other uses, it might indeed make sense to move it
 into libdns++, since one will always depend on the other. We should then
 also seriously consider making it fully optional then.

 > Another discussion point at the design level: with the current set of
 > functions it seems we cannot compute the digest incrementally; we need
 > to prepare an entire block of data to be signed/verified and pass it
 > to the sign/verify function.  This would also mean, e.g., we need to
 > copy incoming DNS message (which could be large) to somewhere and
 > tweak it for sign/verify (such as adjusting the DNS header) and pass
 > the copy to the sign/verify function (I notice ldns works that way).
 > I'm afraid its overhead may not be marginal.
 >
 > BIND 9's crypto interface allows incremental computation of the digest
 > by providing interfaces to both "update" and "final".
 >

 I considered this, but didn't really see the point; the only advantage is
 that you can make the 'tweaks' directly to update(), but in essence you're
 rebuilding the Renderer again then (which is, of course, one way to go).
 For message size considerations I don't think it's necessary. Either way
 you need to prepare the wire format fully for compression, and make sure
 there is no 'second' rendering, if that would change the format.

-- 
Ticket URL: <http://bind10.isc.org/ticket/781#comment:10>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development