Subject: Re: Suggested modifications to the TSIG draft

From: Lea Viljanen <[email-masked]>
Date: Thu, 01 Oct 1998 02:55:29 -0400

Thank you for spelling out some thoughts I've had implementing
TSIG (and some things I hadn't thought at all, too).

However, there is one problem:

> - [4.3] Error returns:
>   * BADAUTH response:  The response will be unsigned, as the problem lies
>   with the key used.  The server cannot definitively determine another
>   key to sign the data with, so no key is used.

While this is the only practical choice here, it would make room for 
a spoofed TSIG BADAUTH DoS attack. I.e someone malicious could inject 
a BADAUTH packet in the middle of the dialogue and cause the communication
to fail.

If we cannot prevent this, we should at least make this problem known.

-- 
Lea 'LadyBug' Viljanen                          NameSurfer Ltd               
[email-masked]                     WWW-based DNS-tools

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Thu, 01 Oct 1998 16:03:18 -0400

If a secure exchange is going on, the resolver that sent a signed
request should ignore all responses that are not signed.  That's why I
oppose this change.  True, if there is no other key available, the
best you may be able to do is an unsigned response.  But if the server
thinks there are any other keys shared, it should just pick one at
random and sign the response with it.  At worst, that will be a bad
signature and the resolver will still ignore the response.  But it
might be a good signature which can at a minimum securely confirm
there is a problem and at best signal a key change so the resolver can
resend the request with a working shared key.

Thanks,
Donald

From:  Lea Viljanen <[email-masked]>
X-Authentication-Warning:  opsmail.internic.net: majordom set sender to owner-namedro
[email-masked] using -f
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
Message-Id:  <[email-masked]>
To:  Brian Wellington <[email-masked]>
cc:  [email-masked]
In-reply-to:  Your message of "Wed, 23 Sep 1998 17:21:02 EDT." 
	      <[email-masked]>
Date:  Thu, 01 Oct 1998 02:55:29 -0400
Sender:  [email-masked]
Precedence:  bulk