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

David Schinazi <> Thu, 11 July 2019 21:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 246F9120156; Thu, 11 Jul 2019 14:44:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 ZUK_ZdGB0n-S; Thu, 11 Jul 2019 14:44:34 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D1762120123; Thu, 11 Jul 2019 14:44:33 -0700 (PDT)
Received: by with SMTP id h28so5055521lfj.5; Thu, 11 Jul 2019 14:44:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U65N0PrkOpB/Jav3ny95bdNQYarSDjvMbnryx9A1CEo=; b=qJrXgUngFYkzKatZ8IiX41rtU5kSkbTvcwh3UYENKYlVNkU5FKCH/Uj5XOyuoWRkJ3 jGI3xVvxhcfw0ijCiBKVRXk4JIJ5rF4veE4dlOMD84zhOYPqpy9szV3CWyjI5U3RBADc 4LredKCftz6h5DLLA6rBHsZptlBwXpu+xgCDe8DriIDaLUOEqR3vZVoH5BozcJQ3uuTc MZ77+KxNPjrPH4zWx48Jshcrgb72QU5M/1vpCwoellfL9ROtryIA+aIrPDrJRc3x7JZn CqQTO1w7ns0fCFhApjJYRovFv8Gyfj7YTJCd7pu92frJjcb3YAfDA2atQeGVtO6rw3EQ tEeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U65N0PrkOpB/Jav3ny95bdNQYarSDjvMbnryx9A1CEo=; b=ct0jOBqvSE2PyeUMYV61ZnXZVIsFDHd+n6s412lMBneYEg39aSGRrmPlAm7IHH4G0H kK8Q6aDo3su129A5O7RyccKVn6m8NcTIT89KdgOXF/9gZhvO/yO+uXO2an7HKVpDBuKx tEfr7R+6JMhiOHzEXl6KZvyJ2JhToxwhJ4vLADlDBWRBSEwXWiSTjaFRQFx4r2esO3Ue TK9fewVu3RQx1qgZMz+/+ShvLve8dM4sXYoFK+AAtPqjp2xFq8wIW5Dp3qQQz492Avhv 8TWK5BVUXp93OdK2siUC7Kd6wBrMrKzAJFbmeffn8pjbJMJJv9E6ph26pQ0fzPwpgsfv gZ0w==
X-Gm-Message-State: APjAAAWzogv7Updn2B/Jg7OvseDwLKnEOKfA2NSeqQ3Q/RroThhK+F2T XTN9iqlPR4YSaq1VDwR5JqbBAOCsE0E+XV8BzRg=
X-Google-Smtp-Source: APXvYqxiRKiXn8Rlvu/5rLzm1MEM7lXCJdAo62L4aODnZojmN2w4aiu04H+j2PPIXdQ2we5wstZetDxAKn+eRSQtwsA=
X-Received: by 2002:ac2:514b:: with SMTP id q11mr2997492lfd.33.1562881472008; Thu, 11 Jul 2019 14:44:32 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: David Schinazi <>
Date: Thu, 11 Jul 2019 14:44:20 -0700
Message-ID: <>
To: Tom Pusateri <>
Cc: Ted Lemon <>, Stuart Cheshire <>, Eric Rescorla <>, DNSSD <>,, Robert Sparks <>
Content-Type: multipart/alternative; boundary="000000000000f71848058d6eb2ba"
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 21:44:37 -0000

To reiterate my earlier point, TLS close_notify DOES NOT protect against an
attacker closing the connection by sending a FIN or RST.
The benefit of close_notify is to protect against truncation attacks: if an
attacker sends a FIN or RST in the middle of a stream,
the recipient application should ignore the current message instead of
considering it complete.
This is important for protocols such as HTTP/0.9 that rely on the TCP FIN
instead of using prefixed lengths.
Given that DSO messages contain a prefixed length, making sure
implementations do not act on partial messages is sufficient to prevent
truncation attacks.
If my understanding is correct, DNS-PUSH does not get ANY security benefits
from close_notify.

When a critical error occurs, a TCP RST should cause the other side to tear
down state more aggressively than a close_notify, which is what we want.

I'd recommend using close_notify for gracefully closes, and TCP RST for any
critical failures.

I agree with Ted that if an implementation is broken it's best to have it
fail very visibly.


On Thu, Jul 11, 2019 at 11:20 AM Tom Pusateri <> wrote:

> If a client implements PUSH, it implements DSO which means it implements
> 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.
> Tom
> 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