Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20
Eric Rescorla <ekr@rtfm.com> Fri, 12 July 2019 04:43 UTC
Return-Path: <ekr@rtfm.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 5CF4D120182 for <dnssd@ietfa.amsl.com>; Thu, 11 Jul 2019 21:43:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.601
X-Spam-Level:
X-Spam-Status: No, score=-0.601 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_NONE=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=rtfm-com.20150623.gappssmtp.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 AEAqZR_ijmIU for <dnssd@ietfa.amsl.com>; Thu, 11 Jul 2019 21:43:22 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 0D4DA120168 for <dnssd@ietf.org>; Thu, 11 Jul 2019 21:43:22 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id 16so7977740ljv.10 for <dnssd@ietf.org>; Thu, 11 Jul 2019 21:43:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mK1/H9Oo1KBE0RZYsDmzGWRrT/z0H2JVpGOKe2yZ1Vs=; b=cWNtCKP7lMNvApWItym5UqTqkful0DbFMoMy5huxfFJXJbDSdcx6cBTOECHsTR74LS uCFWtAW5oTO5whdKxCYPP1OkqAn+zcWuTgshlvDUP72Dj9DD84uKz4aRD0KGK7Qd8f2Y Xt4mPPP2gTiQFTqexy1duw3vRppNPMnab6iQhXwqBNpihlvcQ8Qy7sUtikZaKW3wPh84 Ms7vxTgNl6rxF7EmyxeN+B9HeC7F76BCWydFSsDYXhbCjBBvKGcSAsbGeg1eU+DPis/Q k9LDN2SdZbQBiiDgfe0EVL8GHXhOYajFKyvG1i6sA756pOgbf+76bQpdxCJWTKjbnxXf PrGw==
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=mK1/H9Oo1KBE0RZYsDmzGWRrT/z0H2JVpGOKe2yZ1Vs=; b=rf7w+n0jAtnM2O9DjjIGYSw1HMSEJi71EIzbkmQI/Vf/pCEs83s5OzbLMFSyYDZnB8 oxTV2m1hWH8aYOr1VWmTGVPflifyiDnjPy374FZ6MhEm2b+VL0JRff/IleTQwsWwAqXs xlxevYX7EzhUBzR1ylEMWr/DMSbjQmnfTx1IkPudRIJUyFXRWSNL+EJ4FNPPiySUxgQD jj1FH8BWxhH/NjqMZSK1W3tFme/AG+SNaUlk0EpMzKi9OFcoAFnlFZ+51WdYpiGcXWw2 KvLt7jebELfgU2ntTRrwIz1gtW1X2jIrhLT6CA7pZlRFvn3cxV7K83/CMPAZhDyhExmB 8J6Q==
X-Gm-Message-State: APjAAAUh+2o33151Df+6phdi8HHv/E/XQbZl0Vdzc/tuSmKZ4M1WVH4t wCli38UjUOwOcOa0dxwXwzqIzXPdkchp8VqESv4=
X-Google-Smtp-Source: APXvYqy22gG+wYPmaScycj+J+yKNiMw0aexWs9NNBeush2pks+niCr0CJBSIp6LMmBxlrGGmu7CCY4P0SGR/Rx13FGg=
X-Received: by 2002:a2e:9b84:: with SMTP id z4mr4646007lji.75.1562906600306; Thu, 11 Jul 2019 21:43:20 -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> <CAPDSy+6snSNkN7iRrVwgS5V4Wf3w2hRSwxm1kAmvfW6o7h8aMA@mail.gmail.com>
In-Reply-To: <CAPDSy+6snSNkN7iRrVwgS5V4Wf3w2hRSwxm1kAmvfW6o7h8aMA@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 11 Jul 2019 21:42:42 -0700
Message-ID: <CABcZeBNSVhZ_7iF69m8jntSCysV23TFR3a1zsKczQykQ8kUOcA@mail.gmail.com>
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: Tom Pusateri <pusateri@bangj.com>, Ted Lemon <mellon@fugue.com>, Stuart Cheshire <cheshire=40apple.com@dmarc.ietf.org>, DNSSD <dnssd@ietf.org>, draft-ietf-dnssd-push.all@ietf.org, Robert Sparks <rjsparks@nostrum.com>
Content-Type: multipart/alternative; boundary="000000000000ba8b3d058d748cb2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/i8e46KZuIBQ6ao__PeWLnGlQKkY>
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: Fri, 12 Jul 2019 04:43:25 -0000
On Thu, Jul 11, 2019 at 2:44 PM David Schinazi <dschinazi.ietf@gmail.com> wrote: > To reiterate my earlier point, TLS close_notify DOES NOT protect against > an attacker closing the connection by sending a FIN or RST. > Just to clarify: it allows the receiver to distinguish between closes which were initiated by the peer and those which were not 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. > Well, maybe. You could, for instance, log an error if a finished was received without a close_notify. -Ekr > 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