Re: [dnssd] I-D Action: draft-ietf-dnssd-srp-00.txt

Tom Pusateri <pusateri@bangj.com> Wed, 24 October 2018 20:35 UTC

Return-Path: <pusateri@bangj.com>
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 6B325130E19 for <dnssd@ietfa.amsl.com>; Wed, 24 Oct 2018 13:35:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Md86uKBajKND for <dnssd@ietfa.amsl.com>; Wed, 24 Oct 2018 13:35:16 -0700 (PDT)
Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C97F130E18 for <dnssd@ietf.org>; Wed, 24 Oct 2018 13:35:15 -0700 (PDT)
Received: from [172.16.10.126] (unknown [107.13.224.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 6D7762225D; Wed, 24 Oct 2018 16:35:14 -0400 (EDT)
From: Tom Pusateri <pusateri@bangj.com>
Message-Id: <F3A5B26B-015A-4485-8630-B0B5F100CA6F@bangj.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_58BB36BD-CEA6-4CDE-B55B-785CD9B40C4F"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 24 Oct 2018 16:35:12 -0400
In-Reply-To: <CAPt1N1kgjWxa-ftwA67BSuVme2xN29Gz84sSRKvW0BfAmgiyMw@mail.gmail.com>
Cc: dnssd <dnssd@ietf.org>
To: Ted Lemon <mellon@fugue.com>
References: <154030974108.31401.380315367024024351@ietfa.amsl.com> <99A9AE56-486D-4FF9-81D7-2EE9E372C808@bangj.com> <CAPt1N1kgjWxa-ftwA67BSuVme2xN29Gz84sSRKvW0BfAmgiyMw@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/zjhfAsq8GpPEGNPoifprrOQlbVY>
Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-srp-00.txt
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 24 Oct 2018 20:35:19 -0000

Looking at the archive, Toke was the only other person that commented and he didn’t specifically comment about the name, just that he supported adoption.

So that’s 1-1 not counting the authors.

Maybe encryption was more specific than I meant to state as a concern. From the document:

"SRP updates have no authorization semantics other than first-come,
first-served.  This means that if an attacker from outside of the
administrative domain of the server knows the server's IP address, it
can in principle send updates to the server that will be processed successfully.
Servers should therefore be configured to reject updates from source
addresses outside of the administrative domain of the server.”

The main problem is that it’s restricted to an administrative domain.

And previously, you stated that encryption would break the goals of the protocol because it’s supposed to be done in a single message which can’t happen when using DoT.

Tom

> On Oct 24, 2018, at 3:55 PM, Ted Lemon <mellon@fugue.com> wrote:
> 
> Hm, my recollection is that there was a long discussion on the mailing list, and you were the odd man out.   In any case, SRP can be done over DoT, so encryption is certainly possible if required.
> 
> On Wed, Oct 24, 2018 at 2:13 PM Tom Pusateri <pusateri@bangj.com <mailto:pusateri@bangj.com>> wrote:
> If you were present in Montréal, you may remember that I supported this work for adoption but wanted to see the named changed.
> 
> There didn’t seem to be any other responses one way or the other. Since I believe in rough consensus, it would be good to know if others feel the same.
> 
> The discussion was then moved to the list and can be found in the archives.
> 
> My main objection was that because it wasn’t possible to use encryption with this scheme, it was not a general purpose solution and had to be restricted to a subset of the use cases. Therefore, it should have a name that reflects it’s inherent limitations.
> 
> Thanks,
> Tom
> 
> 
> > On Oct 23, 2018, at 11:49 AM, internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> wrote:
> > 
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF.
> > 
> >        Title           : Service Registration Protocol for DNS-Based Service Discovery
> >        Authors         : Stuart Cheshire
> >                          Ted Lemon
> >       Filename        : draft-ietf-dnssd-srp-00.txt
> >       Pages           : 19
> >       Date            : 2018-10-23
> > 
> > Abstract:
> >   The Service Registration Protocol for DNS-Based Service Discovery
> >   uses the standard DNS Update mechanism to enable DNS-Based Service
> >   Discovery using only unicast packets.  This eliminates the dependency
> >   on Multicast DNS as the foundation layer, which greatly improves
> >   scalability and improves performance on networks where multicast
> >   service is not an optimal choice, particularly 802.11 (Wi-Fi) and
> >   802.15.4 (IoT) networks.  DNS-SD Service registration uses public
> >   keys and SIG(0) to allow services to defend their registrations
> >   against attack.
> > 
> > 
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/ <https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/>
> > 
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-dnssd-srp-00 <https://tools.ietf.org/html/draft-ietf-dnssd-srp-00>
> > https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-00 <https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-00>
> > 
> > 
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> > 
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> > 
> > _______________________________________________
> > dnssd mailing list
> > dnssd@ietf.org <mailto:dnssd@ietf.org>
> > https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf.org/mailman/listinfo/dnssd>
> 
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org <mailto:dnssd@ietf.org>
> https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf.org/mailman/listinfo/dnssd>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd