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        |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Some initial feedback:

 First, I made a few trivial editorial cleanups and pushed them to the
 branch (commit 4f1d8d0).

 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)

 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()?

 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++.

 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".

 Considering our primary use cases of TSIG will be zone transfers and
 dynamic updates, which would relatively be less performance sensitive,
 the above copy overhead might be acceptable if this helps make other
 part of the interface/implementation simpler and more understandable.
 But I think we should at least consider pros and cons of both designs
 and then pick up one.

 At this point I'll give the ticket back to Jelte.

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