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

From: "Levon Esibov" <[email-masked]>
Date: Wed, 24 Jul 2002 09:11:22 -0700

Below, please.

> -----Original Message-----
> From: Rob Austein [mailto:[email-masked]]
> Sent: Tuesday, July 23, 2002 10:36 AM
> To: [email-masked]
> Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to
> Proposed Standard
> 
> 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
[Levon Esibov] 
GSS-TSIG algorithm enables secure dynamic DNS updates. Latter is widely
used/deployed in the intranets of large number of organizations. If we
break backward compatibility then new DNS servers will not be able to
support the secure dynamic DNS updates based on the GSS-TSIG mechanism.

> why is the correct solution not just for the vendors to ship patches?
[Levon Esibov] 
Of course this is a legit possibility. But in my opinion such approach
puts too large burden on users (read administrators) since administrator
of each organization using secure dynamic update will have to deploy
such patch on all (or at least on a large number) of the clients in the
enterprise. Taking into account the number of organizations affected, I
think we should consider alternate solution.

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

[Levon Esibov] 
Any TSIG experts care to comment whether they see any problems with
proposed modification?

Thanks,
Levon.

--
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: Brian Wellington <[email-masked]>
Date: Wed, 24 Jul 2002 09:33:34 -0700 (PDT)

> Any TSIG experts care to comment whether they see any problems with

It causes many clients to break, since a client may treat a signed
response to an unsigned query as an error, and at least one common
implementation does.

Brian