Subject: Re: DNS SRV question (was Re: please post updated draft)

From: Jeffrey Altman <[email-masked]>
Date: Wed, 27 Oct 99 20:25:50 EDT

> one reason for the statement originally (I think) was that some protocols 
> get badly broken, or have funny security risks, when you add the ability to 
> redirect their ports by munging the DNS.

Such as?  I can't imagine a security risk this is added by using SRV
records that isn't already present by simply using DNS because DNS in
its current state is insecure.

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [email-masked]

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 28 Oct 1999 08:00:33 +0200

At 20:25 27.10.99 -0400, Jeffrey Altman wrote:
>> get badly broken, or have funny security risks, when you add the ability
>> to redirect their ports by munging the DNS.
> records that isn't already present by simply using DNS because DNS in its
> current state is insecure.

the ability to stage attacks that only hurt the subset that have (or have 
not) implemented SRV support is one.
if DNSSEC is used, not only the example.org zone must be secured, but also 
the _tcp.example.org zone - NXT must be used to protect against the 
gratuitous insertion of _tcp subzones into sites that do NOT support them.

Using weights to redirect a sample of traffic to a man-in-the-middle 
without affecting the flow of ordinary traffic enough to make target notice.

off the top of my head,

                               Harald

--
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: Terry Lambert <[email-masked]>
Date: Thu, 28 Oct 1999 13:36:57 -0700

Jeffrey Altman wrote:
>> one reason for the statement originally (I think) was
>> that some protocols get badly broken, or have funny
>> security risks, when you add the ability to redirect
>> their ports by munging the DNS.
> 
> Such as?  I can't imagine a security risk this is added
> by using SRV records that isn't already present by simply
> using DNS because DNS in its current state is insecure.

Things break anywhere there is shared state.

Case 1:

	I contact an HTTP server
	It requests I authenticate

	I authenticate
	It sends me session specific information

	I attempt to contact it again to obtain content
	** SRV redirects me to a different server
	The server rejects me because it does not share
	    authenticator state with the original server

Without an agreement between all of the servers participating
in a "SRV cluster" to maintain shared context, thing break.

Case 2:

	I contact an HTTPS server
	I start a Diffe-Helman exchange
	*** SRV redirects me to another server in the middle
	Portions of the server state _are_ shared
	I now have an undetectable man-in-the-middle, since
	    I have to allow redirects to occur, and have
	    not specified the means of securing the state
	    sharing mechanism

Again, I can get around this by mandating shared state
and secure connections for sharing of state, but I
haven't done that in an RFC anywhere, so the inter-server
communication, not having been specified, is subject to
back-end compromise.

Security requires that all channels, including implied
covert channels, be trustworthy to some minimum degree
for the overall communication to be trustworthy to that
degree.

There is a reason IPSEC is incompatible with NAT...

-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.