Re: [dnssd] Secdir telechat review of draft-ietf-dnssd-push-19

Tom Pusateri <> Fri, 17 May 2019 15:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2D6C12026C; Fri, 17 May 2019 08:59:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tKwZxbo-xNJc; Fri, 17 May 2019 08:59:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F1F5B12025E; Fri, 17 May 2019 08:59:23 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id DBDBD2FD85; Fri, 17 May 2019 11:59:22 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Tom Pusateri <>
In-Reply-To: <>
Date: Fri, 17 May 2019 11:59:22 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Liang Xia <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [dnssd] Secdir telechat review of draft-ietf-dnssd-push-19
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 May 2019 15:59:29 -0000

Thanks for the review.

I can confirm that both nits need fixed.

As far as your comments:
1. UNSUBSCRIBE and RECONFIRM are unidirectional because they are already acknowledged by the transport protocol and there is nothing the client can do in response to a DNS level Stateful Operations acknowledgement from the server.

If an UNSUBSCRIBE fails, it’s because it’s not subscribed and the end result either way is that it’s not subscribed.

A RECONFIRM may trigger additional queries from the server which may or may not result in PUSH notifications but the client has to deal with the situation the same until a PUSH notification is received.

2. As far as using the DNS header MESSAGE ID in an UNSUBSCRIBE, this is a consequence of not reusing outstanding message IDs over stateful operations. This means the server must keep the state of the message id and so associating it with the subscription is natural.

Will also address TLS comments.


> On May 17, 2019, at 3:47 AM, Liang Xia via Datatracker <> wrote:
> Reviewer: Liang Xia
> Review result: Has Issues
> Nit:
> 1. Section 6.1, s/This connection is made to TCP port 853, the default port for
> DNS-over-TLS DNS over TLS [RFC7858]./This connection is made to TCP port 853,
> the default port for DNS-over-TLS [RFC7858]. 2. Table 2, RECONFIRM should be
> C-U TLV type.
> Comments:
> 1. why are UNSUBSCRIBE and RECONFIRM the client unidirectional message?
> 2. In UNSUBSCRIBE message, why do you choose to use SUBSCRIBE MESSAGE ID, not
> NAME+TYPE+CLASS? 3. In the section of Security Considerations:
>    1) you should also mention that TLS provides the anti-replay protection
>    service for DNS Push; 2) maybe you need to consider the client
>    authentication to achieve policy control and detect illegal client; 3) TLS
>    WG are specifying the SNI encryption mechanism, will it influence your TLS
>    name authentication?
> _______________________________________________
> dnssd mailing list