[bind10-dev] Tsig class

[JINMEI Tatuya / 神明達哉]

I basically think we should move forward with whatever works for now,
so the following comments are rather for middle-term plans.

At Fri, 26 Feb 2010 14:09:19 -0600,
Michael Graff <mgraff at isc.org> wrote:

> My plan was to create a new Tsig(Name, algorithm, key-data) and then use
> it to sign messages, something like:
> 
>   tsig.signMessage(message);
> 
> and verify
> 
>   tsig.verifyMessage(message);
> 
> where "message" is a dns::Message.  However, I'm not certain about a few
> things.
> 
> One, the signature is actually added into the message.  This means
> signMessage() may add stuff that MUST go to the end, so Message needs to
> become smarter about Tsig.  I'm wondering if I have this backwards, and
> this logic should instead go in Message, so it would call Tsig.sign()
> and Tsig.verify().

I'd like to keep message and Tsig as independent as possible each
other.  So, ideally, a message implementation doesn't have to know
TSIG specific details such as it must be located at the end of the
message, and the tsig can sign/verify the message as opaque data.

I know protocol level requirements make it difficult if not
impossible, but I hope we can do it better than BIND 9 (where the
message module and tsig module are closely related, and a change on
one would easily require a change on the other).

I'd also like to avoid hardcoded conditional behaviors with TSIG or
SIG(0), assuming we'll support both.  In BIND 9, the message
implementation has code something like this

    if (tsig) {
       tsig specific behavior
    }
    ...
    if (sig0) {
       tsig specific behavior
    }

I wonder whether we could unify such cases, by, e.g., having an
abstract level class and let TSIG and SIG0 be inherited from it:

class MessageSigner {...};
class TsigSigner : public class MessageSigner { ... };
class Sig0Signer : public class MessageSigner { ... };

> Lastly, Tsig is also the RRType name.  Will this lead to confusion if we
> have both of these?
>   isc::dns::Tsig
>   isc::dns::rdata::TSIG
> 
> If so, this will be called TrustedSignature which is what Tsig stands
> for.  Luckily we don't have to use it many places.

I don't have a strong opinion on this, but if this could be confusing
I think it's easy to find a reasonable alternate name for the former
(e.g. as Evan suggested).

---
JINMEI, Tatuya