Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard

From: Rob Austein <[email-masked]>
Date: Tue, 23 Jul 2002 13:35:55 -0400

At Tue, 23 Jul 2002 09:14:09 -0700, Levon Esibov wrote:
> 
> I-D based code is widely deployed. Namely it is included in Windows 2000
> Professional and Windows XP Professional, all versions of Windows 2000
> Server and Windows.Net 2003 Server, Lucent DNS Service 3.1 and VitalQIP
> 6.0.

Ok, it's deployed.  Which leaves the other half of the question: how
badly will lack of backwards compatability harm the users?

In case it's not clear: there's a lot of stuff out there that's
deployed but not used (in any operating system, I'm not picking on
Windows here), so the fact that code has shipped doesn't automatically
imply a need for backwards compatability.  What will this break, and
why is the correct solution not just for the vendors to ship patches?

> Just to clarify, my proposal to update Section 4.2 of RFC 2845 (TSIG)
> addresses wider issue than enabling backward compatibility (enabling
> backward compat is just a side-effect of the proposed modification).
> Namely my proposed modification removes unnecessary restriction to use
> TSIG to sign server's response to un-signed TKEY query in case if secret
> key is established on the server side before it is established on the
> client side.

Why is it that everybody who suggests adding additional complexity to
DNS these days phrases it as removing unnecessary restrictions? :)/2

I don't have a serious problem with your proposed change per se, but
(a) others who've been tracking TSIG and GSS-TSIG more closely might,
and (b) I'm not (yet) convinced of the need to change RFC 2845.

Thanks....

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Danny Mayer <[email-masked]>
Date: Sun, 28 Jul 2002 09:20:23 -0400

>and (b) I'm not (yet) convinced of the need to change RFC 2845.

Has someone looked at the security implications of this? Could this result
in someone being able to break the security of the key?

Danny