Re: [dnssd] Security through Obscurity

RJ Atkinson <rja.lists@gmail.com> Thu, 24 July 2014 13:50 UTC

Return-Path: <rja.lists@gmail.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA9C1A035B for <dnssd@ietfa.amsl.com>; Thu, 24 Jul 2014 06:50:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96BedZ9oGSsM for <dnssd@ietfa.amsl.com>; Thu, 24 Jul 2014 06:50:27 -0700 (PDT)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD871A0343 for <dnssd@ietf.org>; Thu, 24 Jul 2014 06:49:37 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id n12so2824995wgh.9 for <dnssd@ietf.org>; Thu, 24 Jul 2014 06:49:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=PhjSwsGBqrM/+i9aBak7R2yz+meFElSyC1MD+B0rQps=; b=WdGv++p6lYUgWhLza4ehDjdVaz1ECVdivR4CPCkB60XDLF+qAd0P7jEqkZNl5WaCP3 bkINXwCgbxmvVCEAyTOIRi/xNXZVQDa/OEGyRlwy5LrBcyDrveMnDmDyBKyFBtGabzg6 JMkyWX6i24DxAHVdk6eUmucPgawNwwvn2j0v4KyJ/QYH3oVyOVJcEJIcrsBWNWpA9i1I BFxnv6BcBiT0ECrEEvXJUXF4drvCRJRtSG2NzmkuMAKpqABBttHXZ6OIjDwun7TXdLpr FvvwZwSzP+S3qfuE2XEwEfqtQd9eQpnPNZ6X8soSom1XBUxP04cNRZYa2Z2wrWxgMlay WNJw==
X-Received: by 10.180.108.1 with SMTP id hg1mr35776312wib.25.1406209776261; Thu, 24 Jul 2014 06:49:36 -0700 (PDT)
Received: from dhcp-b535.meeting.ietf.org (dhcp-b535.meeting.ietf.org. [31.133.181.53]) by mx.google.com with ESMTPSA id lb3sm16056612wjc.30.2014.07.24.06.49.35 for <dnssd@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 06:49:35 -0700 (PDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Apple Message framework v1283)
From: RJ Atkinson <rja.lists@gmail.com>
In-Reply-To: <EMEW3|faec94f4ff05bea449f9614b93dae254q6NE8Q03tjc|ecs.soton.ac.uk|0E0BC226-E68E-4BC2-99EA-AFF1AF96A5EC@ecs.soton.ac.uk>
Date: Thu, 24 Jul 2014 09:49:31 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <E6F68BE4-7094-45AA-ADD9-4B88BBC87921@gmail.com>
References: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> <20E4ED19-12BD-45D4-B690-8629B552B23B@gmail.com> <0E0BC226-E68E-4BC2-99EA-AFF1AF96A5EC@ecs.soton.ac.uk> <EMEW3|faec94f4ff05bea449f9614b93dae254q6NE8Q03tjc|ecs.soton.ac.uk|0E0BC226-E68E-4BC2-99EA-AFF1AF96A5EC@ecs.soton.ac.uk>
To: dnssd@ietf.org
X-Mailer: Apple Mail (2.1283)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/r5ZgEHcvhrsyrVcIpYaiOxs2GQ0
Subject: Re: [dnssd] Security through Obscurity
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Jul 2014 13:50:32 -0000

On 24  Jul 2014, at 09:07 , Tim Chown wrote:
> Doug, if you mean a 48-bit MAC address being embedded in the IPv6 address,
> see http://tools.ietf.org/html/rfc7217.


All,

I think the notion of predictability of IPv6 Interface IDs
is not germane to the DNS-SD discussions, for the reasons
that various folks (e.g. Stuart Cheshire, Tim Chown, and 
Tom Pusateri) have explained already.  

Separately, in many environments, predictability of IP
addressing of printers (or file servers or ...) is 
operationally DESIRABLE.

However, just for the record, there also are a range of other 
RFCs, long predating RFC-7217, for generating IPv6 Interface IDs, 
going back for more than a decade.  [References at bottom]

I believe these various alternative IPv6 IID algorithms are 
widely implemented and deployed today, and that they have been 
widely implemented and deployed for many years now.

Note, in some environments, especially business environments,
the use of DHCP(v6) is operationally preferable to SLAAC
because it provides PREDICTABILITY in IP address assignment. 

Also, in many environments where DHCP is NOT used, for example
due to the costs associated with DHCP, it is STILL operationally 
DESIRABLE for an IPv6-capable device  (e.g. network printer) 
to have the SAME PREDICTABLE IPv6 address each and every time 
the printer (re)boots.  IPv6 SLAAC with an embedded MAC address 
thus is DESIRED in many environments -- especially for devices
providing services that would be advertised using DNS-SD
(e.g. network printer).

Can we PLEASE get past individual hangups over *solved* problems 
that belong to other IETF WGs (e.g. IPv6 Ops, IPv6 Maint, OPsec)
and instead stay on-topic for DNS-SD ?

Thanks,

Ran Atkinson



REFERENCES:

RFC-3041	January 2001
		Privacy Extensions for Stateless IPv6 
                Address Auto-config

RFC-3972	March 2005
		Cryptographically Generated Addresses (CGAs)


RFC-4941	September 2007
		Revision of RFC-3041

RFC-4942	July 2007
		Support for Multiple Hash Algorithms in
		Cryptographically Generated Addresses (CGAs)

RFC-5535	June 2009
		Hash-based Addresses

RFC-7217	April 2014
		Generating Opaque Interface IDs with IPv6 SLAAC