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

Ted Lemon <> Thu, 11 July 2019 17:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B5752120331 for <>; Thu, 11 Jul 2019 10:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.603
X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fSQHVNwMDjQm for <>; Thu, 11 Jul 2019 10:19:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2CF5E12047C for <>; Thu, 11 Jul 2019 10:19:10 -0700 (PDT)
Received: by with SMTP id a15so5086759qtn.7 for <>; Thu, 11 Jul 2019 10:19:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=afkuRKgm9QG8DmCT8/YUp8FEXi7iULCeP7h1wgiUS6s=; b=WW8fhI+d9kE6duiW/R++Jvkctl+eYTPSR/guso80MS78lM+KXUp97+FEDs5oSghTTk +pwHniH+UHVi17yZuLmTePkShzknh7WSD6/FIZpqH8tBvm621p0NvDUSFqJ0peiKPxGi hueIZAcO8Vciji7RRDYfe9fPjh9XlNYlOxIlGYR7n/ikA5sXczA+X5VVYs/cE/WYmtrn WCZ4iOw8w4DuMIioxpKtNKTiF1sxzf6dpulSMtzZoPbbkV8XgCKHqigqoYP/U2vtZkuI OI7ZykonD8D85gISoq4wahJG7cyeJjzGFzk3GzYHW5HyzccBOQLoxY2oJ6Vj87t1E+iy bb9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=afkuRKgm9QG8DmCT8/YUp8FEXi7iULCeP7h1wgiUS6s=; b=tmpxqabJFaIFfHF1Y3sprney7vIiBUwRzFLJ5OeyM5GioIekn4F25n5NH40u21IGQq zH4y180OrjogFMNS7Xy0b0QG+HKKEsdfSMA8USg6vtlzjga4/QMLJaHxan7z5yfDZkS1 C25aWntm+IGG4aB49w/6NFUP17ngE1C2Rbj3CqY4MWRNTZjAEUJpx2spa8tRhxc37aPC 02sr/HTnvudQ8uBA/TkOhfrwwr5XzD20eJ+N53X1Gg2HKLzOLWw3Ez/l2ZUPWQppPuNC DN5pzYf+fm87LqB7MhB+bWBd+vBlQ9RD4CCFd06YBLGWzP/WmnrYUoBDIkzyXLymo4oh TEzQ==
X-Gm-Message-State: APjAAAXhSyRTDywWYmKTICe9S1Bc7iEqvRuDRVENL82FQkbu6BW/D4t6 +FTkYJ4zd++4EHrLMjB17Yan7g==
X-Google-Smtp-Source: APXvYqz3O89IRAPIP7Yw0lYjPzcsbnnClABPvPSmBFIPUA9g+y0NlicQ/a/oG5EASGtLx1MxhGSPXw==
X-Received: by 2002:a0c:bd9a:: with SMTP id n26mr2777933qvg.25.1562865549140; Thu, 11 Jul 2019 10:19:09 -0700 (PDT)
Received: from ?IPv6:2001:470:c1a2:1:1414:e90b:150f:bd61? ([2001:470:c1a2:1:1414:e90b:150f:bd61]) by with ESMTPSA id x23sm2052208qtp.37.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jul 2019 10:19:08 -0700 (PDT)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_34F403E2-273D-431C-AAE1-7BDF85331869"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 11 Jul 2019 13:19:05 -0400
In-Reply-To: <>
Cc: David Schinazi <>,, DNSSD <>, Tom Pusateri <>, Eric Rescorla <>, Robert Sparks <>
To: Stuart Cheshire <>
References: <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
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 17:19:20 -0000

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.