Re: [apps-discuss] Aggregated service discovery

Andrew McMillan <andrew@morphoss.com> Sun, 27 May 2012 03:44 UTC

Return-Path: <andrew@morphoss.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2D621F84C8 for <apps-discuss@ietfa.amsl.com>; Sat, 26 May 2012 20:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level:
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKtTrTSI9oRd for <apps-discuss@ietfa.amsl.com>; Sat, 26 May 2012 20:44:23 -0700 (PDT)
Received: from mail.morphoss.com (hoppy.mcmillan.net.nz [202.78.240.82]) by ietfa.amsl.com (Postfix) with ESMTP id A7B3B21F846D for <apps-discuss@ietf.org>; Sat, 26 May 2012 20:44:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.morphoss.com (Postfix) with ESMTP id 892783C726; Sun, 27 May 2012 15:44:18 +1200 (NZST)
X-Virus-Scanned: Debian amavisd-new at mail.morphoss.com
Received: from mail.morphoss.com ([127.0.0.1]) by localhost (hoppy.mcmillan.net.nz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sT0UoC3Uqm7N; Sun, 27 May 2012 15:44:14 +1200 (NZST)
Received: from [192.168.55.25] (unknown [202.160.48.75]) (Authenticated sender: andrew@mail.morphoss.com) by mail.morphoss.com (Postfix) with ESMTPSA id 106AF3C722; Sun, 27 May 2012 15:44:14 +1200 (NZST)
Message-ID: <1338090233.6923.328.camel@dave.home.mcmillan.net.nz>
From: Andrew McMillan <andrew@morphoss.com>
To: Alessandro Vesely <vesely@tana.it>
Date: Sun, 27 May 2012 15:43:53 +1200
In-Reply-To: <4FBF3F93.2010302@tana.it>
References: <64C6DF43A866F40437AF4CC3@cyrus.local> <22873D37-8462-48AE-ABA0-49445776E4CC@mnot.net> <FF3DD3C9968F397579BC846A@cyrus.local> <92CD7BC1-4A4C-49BD-8F4B-4A04BC63620F@mnot.net> <1337835271.6923.275.camel@dave.home.mcmillan.net.nz> <CA+aD3u0AJ0B4j8YrF4-M7+FmoAJnFzWvYJJ-F8vV87Z3=Y67rQ@mail.gmail.com> <4FBF3F93.2010302@tana.it>
Organization: Morphoss Ltd
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-Vj/QbbuwZa70nZDPl0C9"
X-Mailer: Evolution 3.2.2-1+b1
Mime-Version: 1.0
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Aggregated service discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: andrew@morphoss.com
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 May 2012 03:44:23 -0000

On Fri, 2012-05-25 at 10:15 +0200, Alessandro Vesely wrote:
> On Thu 24/May/2012 16:30:03 +0200 Michiel de Jong wrote:
> 
> > but the main objection people would have to doing this is i think
> > privacy/security. you don't want to announce the exact details of all
> > your services publically, because:
> > 1) it makes it easier for an attacker to know where to attack your systems
> > 2) it may reveal non-public information about your users unnecessarily.
> 
> Requiring authentication in order to discover the services would seem
> to be a relevant functional difference w.r.t. SRV records.  I, for
> one, don't use SRV records because of those two reasons.

I can definitely understand that reasoning, and it's a good point in
favour of a more securable alternative.  You could also make the
relevant SRV records available only on your private networks, but then
that can result in a complex and fragile DNS setup.


> Of course, directing all mass, blind dictionary attacks toward a
> single entry point will call from some savvy implementation advice.
> For example, centralized discovery could count failed attempts and
> block a user when that number becomes comparable to her password's
> entropy.  She won't be able to install new client devices for a while,
> but that is much less disruptive than blocking IMAP access.

I can see plenty of value in an administrator putting the discovery
point inside a corporate (or ISP) firewall in order to reduce the value
to automated external attackers.  Or having alternative representations
of the discovery with only limited visible services for external
visitors.  Analogously, a manual system of providing these configuration
parameters could well place them inside a firewall on internal
documentation.

I would like to see a scheme which had significant utility with only a
single static document providing the information.  More advanced
implementations may well produce that document dynamically, but these
parameters are not expected to be very changeable values in most
installations.

Regards,
					Andrew.
-- 
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com                            +64(272)DEBIAN
        Open Source: the difference between trust and antitrust
------------------------------------------------------------------------