Re: [dnssd] draft-sctl-service-registration call for adoption

Toke Høiland-Jørgensen <toke@toke.dk> Thu, 19 July 2018 18:35 UTC

Return-Path: <toke@toke.dk>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB058130E7F for <dnssd@ietfa.amsl.com>; Thu, 19 Jul 2018 11:35:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk
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 wXcf4uImFfEq for <dnssd@ietfa.amsl.com>; Thu, 19 Jul 2018 11:35:31 -0700 (PDT)
Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30996130E27 for <dnssd@ietf.org>; Thu, 19 Jul 2018 11:35:31 -0700 (PDT)
From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1532025327; bh=9JA4fRtt8sLgqV5oZvSplrk5AfJT4OI1hQd+24sefUg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mOMOkBW+HHMkIW4sv6bj1tZeipqc2pyfcrK6l0cPoCWQOOGncyMg/yCNmVt6SNWDj Qi22zpQU1iqwfVagZqT4zuCtAIvbduMkddb4xz7VqwKgQes0ErTkqlmN7TJuVN3r5k S4i617yZTiHgXMPWqxLqdV+NKZTc1hOvkT8SisQ7nK3YQhpvY7qYgEXjfxnJyq8JbD h6sWuQ9aL9MfMu7ZQ6L5p+4q4JQ17APWGTIlaVdWytpzowhEmdExJZuvf3IJ43fPpG ZoP2mVh93xLCeI08/m8p86XZFViiGVQ/0YS8gS2v6IGFpEGqzsNhTFIg2R6ILeKP2N NPT431XrB8Jtw==
To: Tom Pusateri <pusateri@bangj.com>
Cc: Ted Lemon <mellon@fugue.com>, dnssd <dnssd@ietf.org>
In-Reply-To: <8FF70F87-733C-4DBB-9AAC-85BEA1067105@bangj.com>
References: <9CEB602B-87CA-4F5A-A0B9-C514528AB9AD@bangj.com> <CAPt1N1mg24bD9h6+N7EsBLbo9sDpwyAsN1TnopuZ0eAcdiNw0g@mail.gmail.com> <87y3e719eu.fsf@toke.dk> <8FF70F87-733C-4DBB-9AAC-85BEA1067105@bangj.com>
Date: Thu, 19 Jul 2018 20:35:18 +0200
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87va9b3wgp.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/PCINI5nTbN8CNJdhTk05zD5Lguc>
Subject: Re: [dnssd] draft-sctl-service-registration call for adoption
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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, 19 Jul 2018 18:35:34 -0000

Tom Pusateri <pusateri@bangj.com> writes:

>> On Jul 19, 2018, at 12:23 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> 
>> Ted Lemon <mellon@fugue.com <mailto:mellon@fugue.com>> writes:
>> 
>>> Tom, there are a couple of problems with what you've said. First, the
>>> goal of SRP is actually to provide a general solution for registering
>>> services to be discovered using DNSSD. It is not for constrained
>>> devices only, although that is certainly one case where it's valuable.
>>> So we can't call it a registration protocol only for constrained
>>> devices.
>>> 
>>> Secondly, this is DNS Update. It's just that DNS Update without
>>> something like this *doesn't work* as a registration protocol, and
>>> we've seen that because DNS-SD over DNS hasn't taken the world by
>>> storm in the years since it's been published. This specification is
>>> intended to correct this problem, not to provide a second protocol
>>> that can be used in a constrained set of cases.
>>> 
>>> It's true that FCFS doesn't work for all use cases. This specification
>>> acknowledges that and talks about how to address the problem. We've
>>> also had discussions about this at the mic. This protocol is however
>>> the enabling technology required to solve those problems as well.
>>> Those will be subsets of this, rather than this being a subset of
>>> those.
>>> 
>>> So although I understand where you are coming from, I do not agree
>>> with your analysis of the situation.
>> 
>> As someone whose primary interest in this draft is naming devices across
>> (logical) admin boundaries, I can only agree with Ted here. This is by
>> no means just a thing for constrained devices.
>> 
>> Oh, and I do also support adoption of the draft, if that hasn't been
>> clear from my previous messages :)
>> 
>> -Toke
>
> While you want it to be used for this purpose, it’s not really
> designed for crossing administrative boundaries.
>
> 1. You need encryption which it can’t do because of the multiple
> packets required to do key management.

No, I don't.

> 2. DNS Update does solve the administrative boundary problem at the
> expense of more packets back and forth to the update server. That
> isn’t a problem for you.

I don't care about the number of packets going back and forth, no. What
I care about is not having to distribute keys and configuration to
devices.

> 3. You don’t need the features this draft is good at.

Such as FCFS/TOFU authentication, you mean? Where is that in DNS update?

> 4. This draft could do more than constrained devices but then DNS
> Update already does it.

See above.

-Toke