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

Esko Dijk <esko.dijk@iotconsultancy.nl> Thu, 11 November 2021 09:56 UTC

Return-Path: <esko.dijk@iotconsultancy.nl>
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 CFB103A095C for <dnssd@ietfa.amsl.com>; Thu, 11 Nov 2021 01:56:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancy.nl
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 hoaIt93cEQsd for <dnssd@ietfa.amsl.com>; Thu, 11 Nov 2021 01:56:28 -0800 (PST)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70101.outbound.protection.outlook.com [40.107.7.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0673A0959 for <dnssd@ietf.org>; Thu, 11 Nov 2021 01:56:27 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ggA1jcyAPY9/F4GLa3+gLE0y4SJHXsId/iu/sYpkBNbsj/e2PZzfd0697mqrj4qQFv5pW0403OrQUnUFLI+Qx7OMoe+Q8wkaH3Jzf5nRocKlNBoA+Vnxus+rbrSBAMga6u30M3yAETSAOl5Jiy8DYxF+zQ7ayDTKln6hJolr+vYKJO1eXggsoHzTRgr6C3x750AjABCkTysYwC3stqlqExDZfTaR6TOfCw/mwc5yDR2Eg+UcjRhlMNL63qqpy2s75HN/ODdTnQJ2Y3N5yJJpNKVNoAWlqfX5j6c9rzJOUcBXkz8njtygx4jjkSvPWN9H+8s2ypgeLhoI0D/Pt5kgEA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KwVVd5mGYLjNEI2tAPNfhvfXf6+tQHsD/FplTW6dlo8=; b=BLTQnjcbP2RRt0uWRIQbNQM89OqH6N42q/XLIjIG/uXT9vPAUQGo8USsVHyybrWpf1OjDmYsgLtmgM2F9z8jcZCGmkH7NEdTkGceiNd4eMPIbZXxVFuRskqT++BHBtkxCaA+z5D8n8A+i9KEVqkzMc3GMrEGDyjepTV4qByLV2ZDOFme7S3K/Zu7UMODNo20pZdRe8PX1+jou4ogwTMDD2X5Va6kCOD/D5VsOR8Yn9eAF1ciKvEeClUKOazpghFyk2e7Wkf6dBuNHCo4rXoRvhz5m2eN0PURkg3kPBC7B1vd9JJZGbB12GvmqBMnCr26XDXYHsRLF8m/rL07xRfUFg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KwVVd5mGYLjNEI2tAPNfhvfXf6+tQHsD/FplTW6dlo8=; b=xkUxFcI3FGPodiJ+yI86ZL9GXpZGp+JjDAPHfgzovCBrb7d++8Memg0FMZtDD5/5+7URoLolJHXY3jHT5SH3e+bjF+RGQEFsukPsCTdQtpjfw6gVaJrn3h3Lcn0uFvR1Yrb/ja0mSmCjhiEWQxUHq+/5mpJKIDZMdfDaRjsFYbI=
Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM4P190MB0209.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:64::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.13; Thu, 11 Nov 2021 09:56:22 +0000
Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::c41d:c9d6:d8c7:65c8]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::c41d:c9d6:d8c7:65c8%8]) with mapi id 15.20.4669.016; Thu, 11 Nov 2021 09:56:22 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: dnssd <dnssd@ietf.org>, Ted Lemon <mellon@fugue.com>
Thread-Topic: Review of draft-ietf-dnssd-srp-12
Thread-Index: AdfW1tL8Kth5svk/SH6a9AFCkSftag==
Date: Thu, 11 Nov 2021 09:56:22 +0000
Message-ID: <AM8P190MB09793402CEA9F4BF4B96DC06FD949@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=iotconsultancy.nl;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f7adf2a9-dce0-4a0e-c6ea-08d9a4f984a7
x-ms-traffictypediagnostic: AM4P190MB0209:
x-microsoft-antispam-prvs: <AM4P190MB02098AA8D1495169DC9D0A98FD949@AM4P190MB0209.EURP190.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: S6kkDjGz3Hzt9HS87Oh+JQk74wu8Xavm/C0+HOytjGJCpECvwR4PknQL0Yja37RWjknbYwzGnhKR/Q7r3WWH5Iyj9VmURGWelCSPQdcOZ0XLGc82RkJEM7tN45igsIuFr1piysWuzknOhmsQ0IjGcKuTET8M1ctee4+XyQY8TYDyS+f13jjMCpsY0rwTdNWpAP9DLBQZuprbzPXCM45mvUp3LTVani7PVngFJd7BCFw0XOxm3NbzB9tlDL+CJhvH3/NegRYzCZSBYCqDs9QVMRTEZRP1fQaAZnsAQUnwwE/Mk0XY4UyDhSbiXzHT0F1hhbN1FIEcdq2//xUiGws0oeTnsnCvp9SINPHlZAn+LdQ1VYCvTPeArTi43QqUqAm5spS1kMxk05f9o9inKJqdqtBY5DapD2hbezkxSMQqj0dwXV1Zxv6GHD1gG5JAjHv6A3b7baf+18Q99NEPxBr2gcYM+NCZI64OFUeNaR1DmZ7IMmtbURcMGpA4W/7pFnVPLKktvP3cAPggBvcLE2bJHLb0sobmp320zz9lUwEWXFVUQzlboJlHf3XpGidulBfORVEVk+u3y7Rgt2zQJ+rJkiA95TRiZU8o07/s/WQ4RGh7qxCMIsjAiXS5HqIAidm37JU6TJgwpOxmqPeTtWaTNZQ94XjLLgzJnbfS5grK19pX90yRMFvDe3ayqBQgM1aPlN2rbtPbOzBN2RSGKtPGZbahHKMNE0azPQiSPppWhPtzr82iOnSoaLJwig7EMGpTHbgSy23h5YxJocUt+0JWQA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(136003)(39830400003)(366004)(346002)(396003)(2906002)(66946007)(38070700005)(71200400001)(86362001)(9686003)(8936002)(52536014)(66446008)(5660300002)(55016002)(8676002)(316002)(186003)(110136005)(6506007)(7696005)(508600001)(38100700002)(66476007)(83380400001)(76116006)(44832011)(166002)(33656002)(66556008)(122000001)(64756008); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: gRt6XUOF/+J0gXV82ZO/ZMt5wlexPp4iMVMiN/6acc7s7RxWApQjj4a7X+jD3FW4FzSX9qkUUEiWUYNrtz0raeSlMpnFPZp3TnUzreACqsDLy9XS6gTJKA+hB0JwVA0ugsdz5YRS68EDaqP6gTcvMjWk6nREoaOcDA+MIFLs7Rh0OIs0B3QdsSDUYhByh1L96fqyOGSKPk6cpJnMwkSAd6HifF3pXSgEn42/swaq+li0NN87zYIuZfNC3m2Xum6jsVmzr64HVEerF9sUKYAhDrzg7I4vO1/k6rN3gmd8YdHACctk0lvd1x+g/dJkhj/nndrL0BVOXqxcsgZbOvTZQ2RcXUIdlAn8dGaQDR5I1I1oGi66gqMFUg0uMF9HKHjo1Xmm7yA0RAVQblTY43LNhKZ6bVHfcz/uow/bEG7UzxVreSpOMCde2UoGOYhs4lSw0RCVbQa2U1Ku1KPmC1sR0fusvSRl4YvdWH3YO49WSmkdT2oZCYQkuUTBV8fAHZrD6n6DP+Jl45jYmaaQiaCrYMSaWA0NYrRqOBLU5oXpzPU+TZE6SJGbTy/UrD4EFHmKLMaTFwg/HfdBmLGK0Y+zoxffS2UJe9bY43hf2MlGzCD4YjuFbLWwF8Up1tqtDyTXFIvNx48ebNWTaMTdYYRBIilHljCqMSdPtsIKwtrXOxaaMrELolcRrk1IOSTGEEqwSLTZo+5v0iejQN0+l6azcOnc2Z/SuisCf22VdFYWCRKI5Y/9cx5Fh7TOYNS8j6DLaFX4UEAAFV2NWTejm+vOAjhUOyqi6Cs+m1wp0zxaZlvMhzIC5UxUP4innJoiIE2YAThXZx9VBAZSyfmGQwBfOjN9NnDO9C4Gh1BQwBRQx0n6DQpK5xuHaNrNbpOL9jS4fKhqSX5sKELAHpEIsT6lHjnISLKlAE6NodGGVEaNUzJFgXIzeijzHLCCPozfKTmx0xLZEHrLz6l+T0kzjV4tE1WrtTvm+EEx8mYFlBltsISwERUDX3Xz7KqezK/Mw6KOsHCC4X2nfO0ECIndjrvWgvCc0jvXt1tApbDfopDs8+HBGm9m7nOJQBOsDs9/Ya7mRgEVRQCdAHNh448aSZUPk0250nMgJ/PcOFQ70lhgOUK2swsANb6jua5drjN6FZ6Tto66UGvy5vA/R8QU7hZtaARTumGyiISdlthj7j6rz0+3KHGFDNPt0hXQvtZepDL+xdEesY72xmW5+iVpR7gCqGBKVbWT6l8GGSeWlG5OCFAJ/SYnzjm5I6tKTudbQRorebNViGLoY+f8Z+M3tSiKyYq6YPI5hqlbakEWnE5aDNmvfBplq7tl1cJqoKiHTUq4OnJsy+WbTKSB++IJFPO7PNjKnFkEWhx1UHYtT8kvltmwet9dk5Wj6+C8rzOXsM8Bdpjd1vjuuYo/Is097EcHwRSVVwa1vWPylH6jyZWmodqPmeOz/Bh9AmXHcCGn4gCcdHfZ66mozE3TPOP+QCKoN13wyYOZVM47dl71hE4bhgyd4Vvn/ijMcxAI3nK+mSlEYnKXSN1CobLDjXQDwXwasV60ynDCBPDiu6TsfTSf4Yng90MWNcO48dFBh2jA1KNSogVmkxoeDNN3z0R6ZXltNB8HsC1PnMcqbQu3he+B+535M1MNLP9e2XN0jf+z4UzGH8OM5AKWy+UKZ2hVV+v3/EWOnBCs50+JLhy0gBJIygyWkU/Y7wAHvq59zMzwY0tdLib3ViyyT8+6mb2Hq9Tdqg==
Content-Type: multipart/alternative; boundary="_000_AM8P190MB09793402CEA9F4BF4B96DC06FD949AM8P190MB0979EURP_"
MIME-Version: 1.0
X-OriginatorOrg: iotconsultancy.nl
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: f7adf2a9-dce0-4a0e-c6ea-08d9a4f984a7
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2021 09:56:22.8139 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: mJHwSS4MkxaTakWS585SLkDNGqh5JzEQI4tjgcIE/p/Pra/HuyJOUtKqPD6CqIyOhrZsRsdqOc8eJBhP9oqaIQ5GESpeuttxDnSavteEPYA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0209
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/jxPUz8fgAWS-YaW91zpvqu1DxGI>
Subject: [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 09:56:34 -0000

Thanks Ted for addressing the items of my previous review! Agree with all the changes so far.

Below a few remaining items in the -12 version that still need to be addressed, I think.

*** 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.

*** 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.

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.

*** 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 ;)

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.

Best regards
Esko


IoTconsultancy.nl  |  Email/Teams: esko.dijk@iotconsultancy.nl