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

From: Terry Lambert <[email-masked]>
Date: Thu, 28 Oct 1999 14:31:04 -0700

Jeffrey Altman wrote:
> > 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
> 
> how is DNS SRV going to redirect you in the middle of a DH exchange
> which is taking place over a single tcp connection that has already
> been established?

This is not a DH base authentication, it is a simple
authentication which requires that I return the
negotiated key in the header of my next request.

Since I negotiated with one server, and then returned
the header to a different server, I am screwed.

> > Case 2:
> >
> >       I contact an HTTPS server
> >       I start a Diffe-Helman exchange
> >       *** SRV redirects me to another server in the middle
> 
> how is DNS SRV going to redirect you in the middle of a DH exchange
> which is taking place over a single tcp connection that has already
> been established?

You mistakenly believe that I am running an HTTP 1.1
connection in this example, and that I am permitting
multiple HTTP transactions over a single TCP connection.
I am not.  I am requiring one TCP connection per HTTP
operation, per the HTTP 1.0 specification, and per the
HTTP 1.1 right to refuse to allow persistant connections.
I am doing this in order to force the client to go through
my SRV records, so that I may load-balance it against its
will (but in accord with my own).

You could argue that these cases were degenerate; they
are, however, possible, unless there is a specification
prohibiting them, and thus must be considered for the
protocol to be correct.

> > 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.
> 
> What you are saying is that the above scenarios also break
> if a DNS has multiple addresses for the same name and
> issues them in a round robin fashion.

Yes.

> Since round robin DNS does not break the above
> scenarios then how could it break DNS SRV?

It does break them: I am not allowing persistant
connections, so a reconnect is necessary each time;
consider if I set my TTL on my DNS records to the
minimum allowed value, so that they could not be
successfully cached, and subsequent lookups after
a cache expiration resulted in different addresses.

> If I am missing something really obvious, please let me
> know.  But I don't think I am.

It doesn't break your telnet example, because there is
a persistant connection involved in your telnet example.

The point was to provide examples of shared state between
partners in a client-server relationship, in which the
server answering the request could change between requests;
HTTP fits the bill for this.  I could have easily used NFS
locking against servers with a shared back-end file store
on a Network Appliance box, but that would have been
rather more obscure than an HTTP example.

Without a distrubuted cache coherency protocol to ensure
that the shared state was shared between all the servers
that could respond in a work-to-do way to a single clients
request because the state is not identical on all servers,
breakage results.

I think the point of "SHOULD NOT" (again: "SHOULD"; feel
free to violate it locally) is to discourage application
of SRV records without engaging in protocol considerations
about shared state.

Since it doesn't stop you from doing what you are doing
(though the corrolary is that some clients MAY assume that
you aren't doing it, and behave badly), I don't really see
the problem you have with the wording, except that it
allows clients to behave however they want for a given
protocol, unless there is a protocol specification that
prohibits them from doing so.  I am reminded of RMS's
#pragma implementation in gcc, which started up nethack...

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

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 28 Oct 99 17:03:30 EDT

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

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

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

What you are saying is that the above scenarios also break if a DNS
has multiple addresses for the same name and issues them in a 
round robin fashion.  Since round robin DNS does not break the above
scenarios then how could it break DNS SRV?  

If I am missing something really obvious, please let me know.  But I
don't think I am.

    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]