Re: RFC 2535 transaction signatures

["Donald E. Eastlake 3rd" <dee3@torque.pothole.com>]

Hi Brian,

From:  Brian Wellington <bwelling@tislabs.com>
Date:  Tue, 28 Sep 1999 14:15:08 -0400 (EDT)
To:  "Donald E. Eastlake 3rd" <dee3@us.ibm.com>
cc:  namedroppers@internic.net
Message-ID:  <Pine.LNX.4.10.9909281341150.1409-100000@spiral.gw.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

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.

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

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

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

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

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

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

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

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

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

>Thanks...
>
>Brian

Donald
===================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668   dee3@torque.pothole.com
 65 Shindegan Hill Rd, RR#1  +1 914-784-7913(w)     dee3@us.ibm.com
 Carmel, NY 10512 USA