RFC 2535 transaction signatures

[Brian Wellington <bwelling@tislabs.com>]

I'm in the process of attempting to implement transaction signatures
(SIG(0)), and am running into problems in the description.

- The digested data is specified as:

  	data = full response (less transaction SIG) | full query

  This doesn't include the RDATA fields from the SIG(0) record itself,
  which means that there's no protection against replay attacks.  Should
  this be changed to the following?

	data = RDATA | full response (less transaction SIG) | full query

  If this is changed, it would be nice if it was more like TSIG:

	data = RDATA | query signature | full response (less transaction SIG)

  although a signed response to an unsigned query is possible.

- Even after over 2 years, I still think that a signed response to an
  unsigned query is pointless.  An attacker could easily forge an unsigned
  message, since the client's not expecting a signed response.  The client has
  no method of indicating that it expects a signed response.

- Error handling is not specified at all.  SIG(0) can get around a lot of the
  error conditions present in TSIG, since the key isn't shared, and the
  responder should have a key online with which to sign a response.

  - What if it has no key designated as the SIG(0) generating key?
    Should it return an unsigned response?

  - What if the request SIG fails verification, the key is unknown,
    or the SIG is outside of the validity period?

- Should there be any mention of trying to find a key with an algorithm
  that the client is known to understand?

- What is the owner name of a transaction signature?

- Is there a recommended value for the signature validity period?

- Can transaction signatures be applied to multiple-message TCP streams?

Thanks...

Brian