Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20
David Schinazi <dschinazi.ietf@gmail.com> Thu, 11 July 2019 21:44 UTC
Return-Path: <dschinazi.ietf@gmail.com>
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 246F9120156; Thu, 11 Jul 2019 14:44:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ZUK_ZdGB0n-S; Thu, 11 Jul 2019 14:44:34 -0700 (PDT)
Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1762120123; Thu, 11 Jul 2019 14:44:33 -0700 (PDT)
Received: by mail-lf1-x142.google.com with SMTP id h28so5055521lfj.5; Thu, 11 Jul 2019 14:44:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <CAPDSy+7om=cBW51cyuPea9nabgJuRV3M+++gA7sy8VzfNpkn6Q@mail.gmail.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> <CAPDSy+6V+ooWDe7XezmWA_XKNQXRAOex8DE5CiTnZdz8zc-9CA@mail.gmail.com> <F6DD5CEF-E644-46E3-84B5-18309F6B44C5@apple.com> <270A8516-8BE8-441A-A6CC-4FDE8EFE2B10@fugue.com> <BF75518F-25E9-4283-B647-6382F50A5CCA@bangj.com>
In-Reply-To: <BF75518F-25E9-4283-B647-6382F50A5CCA@bangj.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Thu, 11 Jul 2019 14:44:20 -0700
Message-ID: <CAPDSy+6snSNkN7iRrVwgS5V4Wf3w2hRSwxm1kAmvfW6o7h8aMA@mail.gmail.com>
To: Tom Pusateri <pusateri@bangj.com>
Cc: Ted Lemon <mellon@fugue.com>, Stuart Cheshire <cheshire=40apple.com@dmarc.ietf.org>, Eric Rescorla <ekr@rtfm.com>, DNSSD <dnssd@ietf.org>, draft-ietf-dnssd-push.all@ietf.org, Robert Sparks <rjsparks@nostrum.com>
Content-Type: multipart/alternative; boundary="000000000000f71848058d6eb2ba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/WjIedMSbe3RdYOLeQXc-sYvTVUI>
Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20
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 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. David On Thu, Jul 11, 2019 at 11:20 AM Tom Pusateri <pusateri@bangj.com> wrote: > 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. > > Tom > > On Jul 11, 2019, at 1:19 PM, Ted Lemon <mellon@fugue.com> wrote: > > On Jul 9, 2019, at 10:22 PM, Stuart Cheshire < > cheshire=40apple.com@dmarc.ietf.org> 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 > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > >
- [dnssd] Genart last call review of draft-ietf-dns… Robert Sparks via Datatracker
- Re: [dnssd] Genart last call review of draft-ietf… Tom Pusateri
- Re: [dnssd] Genart last call review of draft-ietf… David Schinazi
- Re: [dnssd] Genart last call review of draft-ietf… Tom Pusateri
- Re: [dnssd] Genart last call review of draft-ietf… Robert Sparks
- Re: [dnssd] Genart last call review of draft-ietf… Tom Pusateri
- Re: [dnssd] Genart last call review of draft-ietf… Robert Sparks
- Re: [dnssd] Genart last call review of draft-ietf… Ted Lemon
- Re: [dnssd] Genart last call review of draft-ietf… Tom Pusateri
- Re: [dnssd] Genart last call review of draft-ietf… Ted Lemon
- Re: [dnssd] Genart last call review of draft-ietf… Tom Pusateri
- Re: [dnssd] Genart last call review of draft-ietf… Ted Lemon
- Re: [dnssd] Genart last call review of draft-ietf… Tom Pusateri
- Re: [dnssd] Genart last call review of draft-ietf… Ted Lemon
- Re: [dnssd] Genart last call review of draft-ietf… David Schinazi
- Re: [dnssd] Genart last call review of draft-ietf… Christopher Wood
- Re: [dnssd] Genart last call review of draft-ietf… Stuart Cheshire
- Re: [dnssd] Genart last call review of draft-ietf… David Schinazi
- Re: [dnssd] Genart last call review of draft-ietf… Tom Pusateri
- Re: [dnssd] Genart last call review of draft-ietf… Stuart Cheshire
- Re: [dnssd] Genart last call review of draft-ietf… David Schinazi
- Re: [dnssd] Genart last call review of draft-ietf… Tom Pusateri
- Re: [dnssd] Genart last call review of draft-ietf… Ted Lemon
- Re: [dnssd] Genart last call review of draft-ietf… Tom Pusateri
- Re: [dnssd] Genart last call review of draft-ietf… David Schinazi
- Re: [dnssd] Genart last call review of draft-ietf… Tom Pusateri
- Re: [dnssd] Genart last call review of draft-ietf… Tom Pusateri
- Re: [dnssd] Genart last call review of draft-ietf… Ted Lemon
- Re: [dnssd] Genart last call review of draft-ietf… Ted Lemon
- Re: [dnssd] Genart last call review of draft-ietf… Tom Pusateri
- Re: [dnssd] Genart last call review of draft-ietf… Ted Lemon
- Re: [dnssd] Genart last call review of draft-ietf… Tom Pusateri
- Re: [dnssd] Genart last call review of draft-ietf… Stuart Cheshire
- Re: [dnssd] Genart last call review of draft-ietf… Ted Lemon
- Re: [dnssd] Genart last call review of draft-ietf… David Schinazi
- Re: [dnssd] Genart last call review of draft-ietf… Eric Rescorla
- Re: [dnssd] Genart last call review of draft-ietf… Jan Komissar (jkomissa)
- Re: [dnssd] Genart last call review of draft-ietf… Michael Richardson
- Re: [dnssd] Genart last call review of draft-ietf… Ted Lemon
- Re: [dnssd] Genart last call review of draft-ietf… Eric Rescorla