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):

 Replying to [comment:10 jelte]:

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

 I'm not sure if my concern was delivered clearly, so let me show you some
 examples.

 1. We are going to sign a response message which is an answer to a signed
 query.  We can get the bare wire format DNS message to be signed, e.g., as
 <renderer.getData(), renderer.getLength()>.  If we have the incremental
 mode, we can incrementally compute the digest for "request MAC" (of the
 signed query), "the wire data" (which can be about 64KB), and "TSIG
 variables".  On the other hand, with the current API we first have to
 prepare a possibly large buffer that can store all these three, and copy
 them into the buffer and then call signHMAC().

 2. We are verifying signed TCP messages.  According to RFC2845, it is
 possible that we have TSIG RR in the first message in the TCP stream,
 followed by multiple  (up to 100) messages without TSIG, and then by
 another message with TCP that also covers all intermediate messages.  To
 verify the second TSIG with the current API, we need to keep all
 intermediate messages and then concatenate all into a single buffer and
 pass it to verifyHMAC().

 Do you think these are okay, or are my concerns a non issue with the
 current API?

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