Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20

Tom Pusateri <> Thu, 11 July 2019 18:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AECE11203B0; Thu, 11 Jul 2019 11:20:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0ZkyQqVaJnjM; Thu, 11 Jul 2019 11:20:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 55DCB1203AA; Thu, 11 Jul 2019 11:20:34 -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 DDF0234766; Thu, 11 Jul 2019 14:20:32 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-0EA95D1B-5B0E-4344-B2EE-4A2984D214D3"
Mime-Version: 1.0 (1.0)
From: Tom Pusateri <>
X-Mailer: iPad Mail (16F203)
In-Reply-To: <>
Date: Thu, 11 Jul 2019 14:20:32 -0400
Cc: Stuart Cheshire <>, Eric Rescorla <>, DNSSD <>,, David Schinazi <>, Robert Sparks <>
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Ted Lemon <>
Archived-At: <>
Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20
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: Thu, 11 Jul 2019 18:20:41 -0000

If a client implements PUSH, it implements DSO which means it implements KEEPALIVE and RETRY DELAY.

That doesn’t mean it will honor every part and it might retry before the delay expires.

But the server sent the retry delay and knows the timeout value and so the server can filter this client for that period of time regardless of whether the client honors it or not. In fact, a server SHOULD do the filtering because the RETRY DELAY is really saying, I’m not going to listen to you until after this timeout.

Also, even if the client closes because of an error, that doesn’t preclude it from using TLS session resumption for the next subscription.

So I’m in favor of always using close_notify and sending a RETRY DELAY for critical errors when needed.

But I think it would be helpful to outline the actual errors that could occur on either end and verify this works in every case. Sending as much information to the other side as possible is helpful for determining bugs. TCP RST signaling doesn’t convey much information.


> On Jul 11, 2019, at 1:19 PM, Ted Lemon <> wrote:
>> On Jul 9, 2019, at 10:22 PM, Stuart Cheshire <> wrote:
>> This is a fine observation.
>> You then suggested changing TCP RST to TLS close_notify, not realizing (a) this is only for fatal errors, and (b) the precedent already set by RFC 8490.
>> We have in fact updated the document, but I think this was too hasty, and we should revert it back to the way it was before.
>> If not, we at least need to have a thorough DNSSD Working Group discussion about this before making a last-minute change to the protocol.
> To add some further nuance from a discussion that Stuart and I had today on this, there are actually several different cases where connection closes are done, and how they should be done is something we should talk about.
> I think in all cases where the client is closing the connection, there’s a case to be made that we don’t want to use close_notify.   It’s true that an attacker can kill our DNS Push connection in this case by forging an RST to the server.   We should discuss whether this is a serious concern that we need to take into account.   If it is, then using close_notify would protect against this iff the server ignores TCP RSTs for active TLS sessions. 
> But the main argument for using close_notify in this case is that we want to be able to resume.   This will not be the case if the client closed the connection because of a protocol error.   It will be the case when the client is closing the connection due to inactivity.
> There is a case where the server closes the connection when the client sends a duplicate subscribe.   That’s because this is a protocol error: the client is broken, and cannot be expected to take corrective action.   Then the question is, do we close the connection down with a retry-delay to make the client go away, or do we just send an RST?
> Argument in favor of sending retry-delay:
> if the client implements it, it will shut up for a while.
> Arguments against:
> If the client doesn’t implement it, it won’t shut up, so we haven’t gained anything
> Making things “sort of work” when the client is broken isn’t all that helpful—we actually want the behavior in this case to be dysfunctional, so that it is noticed and fixed.
> I think that the working group should consider these issues and come to a consensus.
> My own personal opinion is that we should always do close_notify, because if we can assume this, then an attacker can’t kill the connection by sending an RST, if that behavior is implemented in the TLS/TCP stack.   My one doubt about this is that if we are going through a NAT, will the NAT drop its mapping when it sees the RST?   If so, then close_notify doesn’t protect against this attack for a majority of current users.   It still might be worth doing for IPv6, of course.
> As to whether we should use retry-delay, I have really mixed feelings about this.   I want implementations to be visibly broken when they are broken, but I don’t want to have to operate a server that has to deal with broken clients.   The question is whether forcibly disconnecting will actually cause implementors to take action, or whether it will not be noticed and contribute to dysfunction.
> My personal experience is that breaking badly is actually conducive to improvement, so that’s the direction I’m leaning at the moment.
> _______________________________________________
> dnssd mailing list