[prev in list] [next in list] [prev in thread] [next in thread] 

List:       namedroppers
Subject:    Re: RFC 2535 transaction signatures
From:       Brian Wellington <bwelling () tislabs ! com>
Date:       1999-10-01 18:38:29
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]