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

Eric Rescorla <> Fri, 12 July 2019 04:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5CF4D120182 for <>; Thu, 11 Jul 2019 21:43:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.601
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AEAqZR_ijmIU for <>; Thu, 11 Jul 2019 21:43:22 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D4DA120168 for <>; Thu, 11 Jul 2019 21:43:22 -0700 (PDT)
Received: by with SMTP id 16so7977740ljv.10 for <>; Thu, 11 Jul 2019 21:43:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Thu, 11 Jul 2019 21:42:42 -0700
Message-ID: <>
To: David Schinazi <>
Cc: Tom Pusateri <>, Ted Lemon <>, Stuart Cheshire <>, DNSSD <>,, Robert Sparks <>
Content-Type: multipart/alternative; boundary="000000000000ba8b3d058d748cb2"
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: Fri, 12 Jul 2019 04:43:25 -0000

On Thu, Jul 11, 2019 at 2:44 PM David Schinazi <>

> 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.


> 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 <> 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