Subject: Re: RFC 2535 transaction signatures

From: Brian Wellington <[email-masked]>
Date: Fri, 1 Oct 1999 14:38:29 -0400 (EDT)

On Wed, 29 Sep 1999, Donald E. Eastlake 3rd wrote:

> Hi Brian,

Hi again.  Sorry to be so picky :)

> >- 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
> 
> This is a reasonable idea...although it needs a more precise
> definition to include the RDATA less the signature.  And only the
> RDATA for that SIG(0) should be included so if there is more than one
> they don't interact with each other.

Is there any reason that this can't be the same as for a normal SIG, where
RDATA includes all fields except the signature itself?

> >  If this is changed, it would be nice if it was more like TSIG:
> >
> >	data = RDATA | query signature | full response (less transaction SIG)
> 
> The question in my mind is what, if any, implementations there are.  I
> don't object to some changes if implementors don't.  However, Charlie
> Kaufman and I deliberately designed SIG this way so you can get by
> with half as many expensive public key signatures and still have full
> transaction security.

I think a change is needed to address the above problem (replay
protection).  Has anyone implemented this that you know of?

> >  although a signed response to an unsigned query is possible.
> 
> It is extremely hard to protect against denial of service anyway.
> What exactly do you gain by doing twice the work and signing the
> request also?  This is a difference from TSIG because SIG signatures
> are much more expensive.  The requester knows what request they sent
> (and when) so they can safely verify the response signature.

The main advantage is consistency.  If a query is signed, the response
must be signed.  The server will be able to assume that a query is signed
for a reason and validate the signature, instead of parsing the message,
determining if the signature "should" be validated or thrown away, and
then optionally validating it.  The client would have a clear way of
specifying that it requires the response to be signed.  It would expect
that all responses to signed queries would be signed, and again, wouldn't
need to determine whether a response "should" be signed or not.

> >- 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.
> 
> You can not predict all circumstances.  You do not know what the
> client may expect.  RFC 2535 never requires transactions signatures on
> replies.  This is all up to local policy or agreement between the
> parties.  Until we have more operational experience, I think it should
> be defined how to generate a strong transaction signature even when
> the query was unsigned and to do so should not be prohibited.

This leaves a lot to the implementors.  The server and client must somehow
know when to expect a SIG(0), and when the other end expects a SIG(0).
Without an ESP module (Bob's words, not mine), that's really hard to do.

With TSIG, it's perfectly clear.  The only time a TSIG is explicitly
expected is on a response to a TSIG signed query.

> This feature in the design of SIG can be used to cut in half the
> effort involved in setting up a symetric key.  For example, say that
> the client requests server specified keying material by doing a Query
> for TKEY.  The server sends back such keying material in a TKEY
> encrypted under the specified client KEY signed by the server with a
> SIG(0) (see TKEY draft for details).  When the client gets this,
> verifies the SIG, and decrypts the material, both parties have shared
> authenticated symetric keying material.  While the TKEY draft
> recommends that all these messages should be signed, it is not clear
> how signing the request helps all that much.  If you are a denial of
> service attacker, it is just as easy to generate a zillion queries
> with junk signatures as a zillion queries without them.  And certainly
> an imposter can't get the symetric keying material because it does not
> have the client secret key to decrypt it.  So just dropping the
> request signature can save you a factor of two in symetric key set up.
> Maybe some servers will be configured only to SIG(0) transaction sign
> TKEY repsones....

The resolver sends an unsigned request.  It then waits for an answer,
which should be signed.  What if it gets an unsigned answer?  There could
be local policy configured, but it seems that the resolver must "know" to
expect a signed response, but the server can't "know" that the resolver is
expecting this.  An unsigned response can be spoofed, and the resolver
will have to magically decide whether it's a legitimate unsigned response
or a spoofed response.

Again, with TSIG, this is trivial.  The client signs a request and expects
a signed response.

To get around the slow crypto problem, the client could just use a small
key if there's no reason to use a larger one.

> >- 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?
> 
> If the configuration is such that a transaction signature should be
> generated for a particular message, but there is no key, I believe you
> should generate an unsigned message and optionally locally log an
> error.  The response SIG(0) key is normally a key associated with a
> host name of the server.

The server can log an error.  That's easy.  But what does the client do
when it's configured to receive a signed response and gets an unsigned
response?

> >  - What if the request SIG fails verification, the key is unknown,
> >    or the SIG is outside of the validity period?
> 
> Its all local policy and configuration.  RFC 2535 never requires a
> server to check a request SIG(0) except when the request requires some
> privilege for which the requester's authorization depends on the
> request SIG.  I would say the server should generally act as if the
> bad request SIG(s) had not been there.

Again, this is fine for the server, but the client has no idea that a
problem exists unless that information is relayed somehow.

> >- Should there be any mention of trying to find a key with an algorithm
> >  that the client is known to understand?
> 
> If the request was signed, you can assume the client understands the
> algorithm(s) used.  If not, how and whether you sign responses is a
> configuration thing.  You could sign with all the algorithms you have
> keys for, if you were will to pay the computational price.

Seems reasonable.

> >- What is the owner name of a transaction signature?
> 
> As stated in 4.2 (5), it is ignored and recommended to be root to save
> space.

Oops, missed that section.

> >- Is there a recommended value for the signature validity period?
> 
> Not in RFC 2535 or any other document I am aware of.  Considerations
> would be similar to TSIG, I should think.

OK.

> >- Can transaction signatures be applied to multiple-message TCP streams?
> 
> I think they could but if you more than a few messages, it would be
> cheaper to use TKEY to set up a symetric key and then use TSIG.

TSIG would definitely make more sense.  SIG(0) won't work without
modifications to support chaining, though, since there's currently no
prevention of dropped messages unless you replace 'full query' with 'full
last message sent' in the digest function.

Brian

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 06 Oct 1999 00:03:21 -0400

Brian,

From:  Brian Wellington <[email-masked]>
Date:  Fri, 1 Oct 1999 14:38:29 -0400 (EDT)
To:  "Donald E. Eastlake 3rd" <[email-masked]>
cc:  [email-masked]
In-Reply-To:  <[email-masked]>
Message-ID:  <[email-masked]>

>RDATA includes all fields except the signature itself?

No, I think that would be a fine way of doing it if the SIG(0) data
covered definition is to be changed.  (There is, of course, some
protection against replay now in that you can only reply in reponse to
a query with the same serial number.)

>protection).  Has anyone implemented this that you know of?

No, not that I know of...

>need to determine whether a response "should" be signed or not.

As far as I can tell, there isn't any reason to digitally sign a
request unless the request requires some special privilege, such as an
update.  You say that you want to be able to flag a request to say
that you want a signed response.  That's fine, but you sure don't need
even a low effort TSIG, let along an expensive SIG, to provide a one
bit flag do you?  And how does the client know that the server even
supports any king of signature anyway?

If you really want to parallel TSIG as much as possible, we could
allocate a new SIG algorithm number and define the "HASH" signature
algorithm or something which would just be a hash.  Then you could
concatenate that with the result to, cryptographically, get the same
effect as concatenating the query itself, but without the substantial
expense of public key encryption.

>expected is on a response to a TSIG signed query.

There is really no difference.  It's just that with TSIG, your mental
image has all the configuration done at some earlier different time so
you are ignorning all the TSIG configuration required while burdening
SIG with roughly the same amount of congiguration effort you are
ignorning for TSIG.

How does a TSIG client decide whether to sign an ordinary request (one
not needing special privilege)?  Obviously its been configured,
perhaps by the manual entry of a key.  If it signs a request and the
server doesn't have TSIG implemented, then at best the client will
ignore the unsigned result and it won't work, right?  So this
configuration had better be right.

I would think that most cases where SIG was implemented, TSIG would
be also and you would prefer TSIG since it is cheaper.

>will have to magically decide whether it's a legitimate unsigned response

Why do you say that "the server can't 'know' that the resolver is
expecting this"?  For certain types of requests, particularly TKEY,
the server sure does know that only a signed response will be of any
use.  For others cases, it must be explicitly configured, just like
TSIG, only TSIG is configured by key installation.

>Again, with TSIG, this is trivial.  The client signs a request and expects

Installing a TSIG key at both ends is almost exactly the same as
configuring both ends to send/require a SIG(0) all the time.  There is
no substantial difference in the configuration effort.  Misconfiguring
the two SIG(0) ends (client expects signed responses and so discards
unsigned ones but server doesn't sign them) can cause failures just
like bad TSIG configurations can cause failures.

>key if there's no reason to use a larger one.

Where is it going to get this "small key"? Small keys are not secure
so you might as well just use the hash idea above.  That reduces the
request signing effort to approximately that of TSIG.  To get any
security, replies still have to have real SIG(0)s and if the request
requires special privileges, it also needs a real SIG(0), not just a
hash.

>when it's configured to receive a signed response and gets an unsigned

If it's a TKEY type response that must be signed, it needs to toss it
and possibly log an error.  For other responses, there are only two
choice, which could be configuration parameter: either toss it or use
it.

>problem exists unless that information is relayed somehow.

There is no problem if the request did not require a signature.

If the request was privileged or for whatever reason the server
required a signature on it, it will fail and an error should get sent
back.  The client will presumably only notice this error if the server
signs it and the client can verify that signature or if the client has
chosen not to require a signature on responses.

And there is certainly no way you can guarantee any error indication
from the server will ever make it to the client.  If bad guys are
diddling the requests, they can block or diddle responses.

>last message sent' in the digest function.

Probably also a good idea.

>Brian

I don't object much to changing SIG(0) to be more similar to TSIG but
you will never get it exactly the same.  Just changing it so that the
response is signed if the request is doesn't answer the configuration
problem completely.  With TSIG, if a key is installed, you are
assuming the other end has TSIG implemented and the same key.  But
being configured to use a SIG(0) on a request doesn't tell you a thing
about whether the other end has it implemented.

My vision had been that a client only signs requests the need special
privilege.  In fact, clients won't have such operations implemented
unless they also have TSIG or TSIG and SIG(0) capability.

Servers probably always check signatures and toss the request if they
are bad.  If the request requires privileges, it is checks that there
are one or more signatures authenticating that the client has those
privileges.  Servers always sign replies that require signatures and
are configured as to whether other replies are signed or not.  Any
server that can perform requests requiring privilege will have TSIG or
TSIG and SIG(0) capability.

Clients are configured to either always require signatures or only
to require them on the responses which need security (as in TKEY
responses).

While you could imagine more complex configurations, particularly by
treated different destination parties for messages differently, the
above is only one bit of configuration at the client and one bit at
the server.  This bit is essentially the same as the one bit of
information at to whether a TSIG key is installed or not.  Is that so
bad?

I think that for many installations, manually configuring TSIG keys
will be impractical and they will be set up with some automated
mechanism like TKEY.  If it recommended that all requests and
responses involved with TKEY are signed.  So for frequently
communicating secure DNS components, possibly the only use of SIG(0)
will be to authenticate TKEY messages so you can boostrap to having a
symetric key and using TSIG.  For infrequently communicating DNS
components, its operationally mostly a question of whether the server
wants to assume the computational burden of SIG(0)ing responses to
authenticate the header bits.  I doubt that any heavily banged on
server, like .com, is going to want to do that but miscellaneous
servers might.  And even if a server did, it's even less likely it
would want to go to the even greater effort of verifying a real (not
just hash) SIG(0) on a request as they requires fetching and verifying
the host key for the requester.  In fact, if you require a true SIG(0)
on the request to ber verified, you can get into an infinte regress
where the queries to get and verify the public key to authenticate the
request SIG(0) lead to more request SIG(0)s that have to be
authenticated.  I don't think that would happen in the typical stub
case because the recursive server it is, for example, trying to use
TKEY to set up a symetric key with, will either be a secondary for the
zone with the host public key in it or have secure SIG/KEY based
retrieval from that zone.

Donald
===================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668   [email-masked]
 65 Shindegan Hill Rd, RR#1  +1 914-784-7913(w)     [email-masked]
 Carmel, NY 10512 USA