Re: [dnssd] Review of draft-ietf-dnssd-srp-12

Ted Lemon <mellon@fugue.com> Thu, 11 November 2021 22:05 UTC

Return-Path: <mellon@fugue.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 6C7563A0FE4 for <dnssd@ietfa.amsl.com>; Thu, 11 Nov 2021 14:05:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.gappssmtp.com
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 xjGE7q8nkiQw for <dnssd@ietfa.amsl.com>; Thu, 11 Nov 2021 14:05:27 -0800 (PST)
Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8486D3A0FE1 for <dnssd@ietf.org>; Thu, 11 Nov 2021 14:05:27 -0800 (PST)
Received: by mail-ot1-x32c.google.com with SMTP id r10-20020a056830080a00b0055c8fd2cebdso10941191ots.6 for <dnssd@ietf.org>; Thu, 11 Nov 2021 14:05:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EKNAlz8C7yPBBVoGUBA+OOW5qPFmjZa7koXzUBG69js=; b=NVKPH33ANDqhX9Xufv62okqkIwuS9XVvVzlu25k+xKhwElK2oKMC+LIslI/0a/e48J /HB7YVxfSR0QKw1YzVGjMTC+X9n+/9iMmI3lPkA5Fjr0cxIHKP7xp7O7KAq29rf8KzGa qAS7OmSxSpJ2dHbbIiqy3x9kfcVXaRAgM42vd4GHEwt/0tY2//W1kughpjHl2ryYVDxD rs0UPFyeveD0VEyLfAo/a7lC0p8Aqu4mJy90SZXuWWZjfpLFF/k8pzV9b0d0ydgCRTiF WQdopz1gjZy7fqt3DHBqmBlptEvx7dPnWCrGntwQYnZW3yIS6Kky2+tDiqDleWsiKdFs bSzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EKNAlz8C7yPBBVoGUBA+OOW5qPFmjZa7koXzUBG69js=; b=EtGkRQGia7iHNxUJbCeXLm3mBLlZvCs7KpVny48vx87K/NBFNPKyQphxXP3tS0H6Vh SH89Y/smWQkusGdUEvZ0aDC3G4qz0lzdoC6Ot8d+hCR2FbSZwUOTB3P8zGFY0A+234DY MKmE8piqd81a5VkHGR846IkBp4lTP65fCjwybJnC4uIHpmTa1y/SdZn/rPOj9Mi0gAdi Rl9OhcF7hDavLflNtWzAd9gUSoiEaqiOfyssLcZfSfAjz6xvxf3Z0H/nfrTqMYK8Ry7i j2wnzm+tfcrBBXKvY8NnogPyPTBphLjeE75z9uv/03OaWUjbgVqallRJ/5u2gUnVOItD EhHA==
X-Gm-Message-State: AOAM531aZ+SChI104gwnBVnGSRMPWo5IJnsXLA5rRDtDB2eJZTeTi1Hr 1wF35nJKJ6wMt2WeDj6ypmjPQkwZNgPOsyVnKNhBY7uNdoEy/M4O
X-Google-Smtp-Source: ABdhPJwc3FS3zDU/DukMzGtdyZHwg26uTqwEX04EExmgp0SVGmg6AhlW2ja5xzLGm0W+677fnRjh3tMislrsXBEZq8s=
X-Received: by 2002:a05:6830:55b:: with SMTP id l27mr8435378otb.309.1636668325730; Thu, 11 Nov 2021 14:05:25 -0800 (PST)
MIME-Version: 1.0
References: <AM8P190MB09793402CEA9F4BF4B96DC06FD949@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM>
In-Reply-To: <AM8P190MB09793402CEA9F4BF4B96DC06FD949@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM>
From: Ted Lemon <mellon@fugue.com>
Date: Thu, 11 Nov 2021 17:04:49 -0500
Message-ID: <CAPt1N1mgGevBYTL7yyVkZQywjhxESkWytcfpg+v7u3NXFZNmwA@mail.gmail.com>
To: Esko Dijk <esko.dijk@iotconsultancy.nl>
Cc: dnssd <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002bae6b05d08a8a89"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/oVy6P4TXhaC1KhzLzlQICkuGd8I>
Subject: Re: [dnssd] Review of draft-ietf-dnssd-srp-12
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: Thu, 11 Nov 2021 22:05:32 -0000

On Thu, Nov 11, 2021 at 4:56 AM Esko Dijk <esko.dijk@iotconsultancy.nl>
wrote:

> *** Abstract
>
> The abstract text mentions the motivation for DNS-SRP, including details
> about 802.11 and 802.15.4 networks. Now I don’t see this argumentation
> (including the details about 802.11/802.15.4 networks) coming back anywhere
> in the draft. Normally (at least according to best practices in paper &
> report writing) an abstract does not introduce new, additional information.
> It only recaps or summarizes information from the overall document.  So if
> particular details are like the motivation for DNS-SRP, or particular
> suitable network types (802.11/802.15.4) are mentioned in an abstract they
> must also be mentioned somewhere else in the document e.g. in an
> introduction section.  However I don’t see these items coming back in the
> main document: the motivation/rationale for SRP is very minimal there.
>

Okay, this makes sense. I didn't manage to understand that from your
previous comment, even though I'm pretty sure that's what you already said.
:)


> *** 2.3.1.1
>
> (See also my separate emails of August 18/19)  I find the text of this
> section very hard to read. But it does not have to be so complex! My idea
> was to define Service Discovery Instruction in a less detailed way and let
> the existing validation requirements of section 2.3.2 do their work to
> “eliminate” any bad cases of Service Discovery Instruction.  This avoid the
> intricate definition of interrelations between the Instruction types.
>
>
>
> Here is an alternative proposed text:
>
>
>
> An instruction within an SRP Update is a Service Discovery Instruction if
>
>
>
>    *  it contains exactly one "Add to an RRSet" ([RFC2136], Section 2.5.1
> <https://datatracker.ietf.org/doc/html/rfc2136#section-2.5.1>) or exactly
> one "Delete an RR from an RRSet" ([RFC2136], Section 2.5.4
> <https://datatracker.ietf.org/doc/html/rfc2136#section-2.5.1>) RR update,
>        o  which updates a PTR type RR,
>        o  the target of which is a Service Instance Name,
>
>        o  where the Service Instance Name is being used in at least one
> other Instruction in this same SRP Update,
>
>    * and it contains no other RR UPDATEs.
>
>
>
> This should work because due to the Section 2.3.2 validation requirements,
> first paragraphs, already puts in the needed constraints in a much clearer
> & simpler way.
>
> We could discuss the above proposed text to see if people agree whether it
> is 1) clearer , 2) easier to implement, 3) correct,  or not.
>

No, this wouldn't be correct. The additional constraints you want to remove
are to ensure that if the Service Instruction is an Add, the Service
Description Instruction is also an Add, and if the Service Instruction is a
Delete, the Service Description instruction is also a delete. We could
explain that in 2.3.2, but currently we do not.


> Note also the sentence “it contains exactly one "Add to an RRSet" ([RFC2136],
> Section 2.5.1
> <https://datatracker.ietf.org/doc/html/rfc2136#section-2.5.1>) or exactly
> one "Delete an RR from an RRSet" ([RFC2136], Section 2.5.4
> <https://datatracker.ietf.org/doc/html/rfc2136#section-2.5.1>) RR update,”
>
> which is in general also improving the existing text by pointing to the
> correct section numbers.
>
>
>
> Also note the first sentence “An instruction within an SRP Update is a
> Service Discovery Instruction if” which would be an improvement on existing
> text I think, even if the present text is mostly kept.
>
> (though I hope that won’t be the outcome …)
>
>
>
> The existing text in -12 has “Delete RR” pointing to section 2.5.1 which
> is incorrect.
>
>
>
> *** 5 Security Considerations
>
> Given that TLS usage is specified, but that TLS can’t be used for
> authentication as we discussed, should we mention this fact briefly in
> Section 5?
>
> E.g. “although TLS is RECOMMENDED to be used by an SRP client for privacy,
> it does not provide mutual authentication of client and server.”
>
> The current section 5 only has considerations on the security of the KEY
> RR / SIG(0) mechanism but not related to TLS.
>

That seems like a good idea.


> *** 8.2
>
> *** 8.3
>
> In your prior email you wrote:
>
> > That is confusing. The reason for the trailing dot there is that it's a
> fully-qualified domain name, and such names end in a '.' to indicate the
> root label. But I think it's probably clearer to leave out the dot here.
>
>
>
> I’m fine with having the dot in there, if it is needed in there (I
> wouldn’t know). Sorry for perhaps being not clear in my review email. The
> point was this:
>
> In the sentence in 8.2 and in 8.3 (former 9.2/9.3) there’s a grammar issue
> ; two sentences are joined together.
>
>
>
>    Availability of DNS Service Discovery Service Registration Protocol
>
>    Service for a given domain is advertised *using the*
>
> *   "_dnssd-srp._tcp.<domain>" SRV record gives the target* host and port
>
>    where DNSSD Service Registration Service is provided for the named
>
>    domain.
>
>
>
> The sentence is similar to “Availability of taxi service for a given
> neighborhood is advertised using a billboard gives the address where taxi
> service is provided for the neighborhood.”  Doesn’t read too well ;)
>

Right. I again completely failed to understand that from your previous
comment—thanks for clarifying (or re-iterating).


> What about
>
>
>
>    Availability of DNS Service Discovery Service Registration Protocol
>
>    Service for a given domain is advertised using the
>
>    "_dnssd-srp._tcp.<domain>" SRV record*. This record* gives the target
> host and port
>
>    where DNSSD Service Registration Service is provided for the named
>
>    domain *<domain>*.
>
>
>
> And the same fix for Section 8.3
>

That sounds good.

>