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

From: "Levon Esibov" <[email-masked]>
Date: Tue, 23 Jul 2002 09:14:09 -0700

Hi Rob,
please see my comments below.

Thanks,
Levon.

> -----Original Message-----
> From: Rob Austein [mailto:[email-masked]]
> Sent: Monday, July 22, 2002 2:01 PM
> To: [email-masked]
> Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to
> Proposed Standard
> 
> At Mon, 22 Jul 2002 12:09:35 -0700, Levon Esibov wrote:
> >
> > Please respond with your feedback on which solution you prefer.
> 
> Well, if you're going to phrase it that way....  Other things being
> equal, I'd prefer a third option that you didn't list: fix the
> GSS-TSIG RFC-to-be and punt on backwards compatability with clients
> that implemented from the now-known-to-be-broken GSS-TSIG I-D.
> 
> In theory, anybody who ships product code based on an I-D deserves
> what they get if the protocol changes out from under them.  If we're
> going to bend over backwards trying to help such folks out, it'd be
> good if somebody could first explain why this is worth doing, perhaps
> in terms of how widely used the I-D-based code is and how seriously
> those users would be harmed if we ignored the issue.
[Levon Esibov] 
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.
> 
> In other words: bug-compatibility has costs, so it'd be nice to know
> whether the problem is serious enough to be worth paying those costs.

[Levon Esibov] 
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.

For the record: here is my proposal to update Section 4.2 of RFC 2845
(TSIG):
Replace:
"The server MUST not generate a signed response to an unsigned request."

With:
"The server MUST not generate a signed response to an unsigned request,
except in case of response to client's unsigned TKEY query if secret key
is established on server side after server processed client's query.
Signing responses to unsigned TKEY queries MUST be explicitly specified
in the description of an individual secret key establishment algorithm."

--
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: Rob Austein <[email-masked]>
Date: Tue, 23 Jul 2002 13:35:55 -0400

> Server and Windows.Net 2003 Server, Lucent DNS Service 3.1 and VitalQIP

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?

> key is established on the server side before it is established on the

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

---

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