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

Stuart Cheshire <> Wed, 10 July 2019 02:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A0991200C5; Tue, 9 Jul 2019 19:23:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1-HtlVy5-etV; Tue, 9 Jul 2019 19:23:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F9581200CD; Tue, 9 Jul 2019 19:23:00 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x6A2M7IX013899; Tue, 9 Jul 2019 19:22:57 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=0OVvZBAjCPSyQyynzhGkqjpprBpElVWdCNA2uWLdOCM=; b=Ld3tUq/GUw1GqmvNZyrfMNo63ptdKqHuRjM5zJEpthEKTmRjawbcWPWmyrf61ExL+oJ5 SS8HTvdkUo/6ilpLuEou9n2rzQS6VkbFRHlL8u7a/ufRB+vR3xsNdkgP66UzbnkJ0Qcx idCyKC97f2KupemHpDB2qJjgNUSUWEh3G46+3vkE9Eu1E1QG1AthQZIzmkchmb/lTshX BmoibhEXo5woXOwV48S/KbcR0c0MkdQmdLvuxntg2GfhrIL+/aCj2J3aAWsmt69DUKBn +dQneEbDRicnE8ThRaYRUiRs9zsSj+TOA3eVcBoXz+27ce7l9tJUFB6xUKuVY/mgI3x1 1A==
Received: from ( []) by with ESMTP id 2tjtk32gxs-11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 09 Jul 2019 19:22:57 -0700
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built May 7 2019)) with ESMTPS id <>; Tue, 09 Jul 2019 19:22:54 -0700 (PDT)
Received: from by (Oracle Communications Messaging Server 64bit (built May 7 2019)) id <>; Tue, 09 Jul 2019 19:22:53 -0700 (PDT)
X-Va-T-CD: 10a534a1686abdccb129dd18c18ba03f
X-Va-E-CD: 3c579badc8061719d024feec5a8178fb
X-Va-R-CD: dac62b87d893430a0308504ef8763cad
X-Va-CD: 0
X-Va-ID: 6d73c46c-6854-4c62-8e19-e490f1451c36
X-V-T-CD: 10a534a1686abdccb129dd18c18ba03f
X-V-E-CD: 3c579badc8061719d024feec5a8178fb
X-V-R-CD: dac62b87d893430a0308504ef8763cad
X-V-CD: 0
X-V-ID: ff402b2a-03aa-409d-ae5f-d0ade04c5a6f
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-10_01:,, signatures=0
Received: from [] (unknown []) by (Oracle Communications Messaging Server 64bit (built May 7 2019)) with ESMTPSA id <>; Tue, 09 Jul 2019 19:22:52 -0700 (PDT)
Content-type: text/plain; charset="utf-8"
MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Stuart Cheshire <>
In-reply-to: <>
Date: Tue, 09 Jul 2019 19:22:50 -0700
Cc: Tom Pusateri <>, Robert Sparks <>,, DNSSD <>, Eric Rescorla <>
Content-transfer-encoding: quoted-printable
Message-id: <>
References: <> <> <> <> <>
To: David Schinazi <>
X-Mailer: Apple Mail (2.3445.9.1)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-10_01:, , signatures=0
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: Wed, 10 Jul 2019 02:23:03 -0000

On 8 Jul 2019, at 16:05, David Schinazi <> wrote:

> In general the "TLS Alerts" error codes are specific to the operation of TLS itself, not the application running over TLS.
> If you want to send a graceful close, the tool of choice is close_notify.
> If you detect an unrecoverable error and want to abort the connection, I see two options:
> (1) forcibly terminate the connection at the DNS layer by sending a DNS error message followed by a TLS close_notify
> (2) forcibly terminate the connection at the TCP layer by sending a RST
> As a client sending, I don't see much value in (1) since all the server can do in either case is free the resources associated with this connection.
> As a server sending, I suspect (1) is best unless you were unable to parse anything in which case (2) makes sense.

This is a great candidate for some serious discussion in Montréal.

The draft *used* to say to respond to fatal errors by forcibly aborting the connection with a TCP RST. This is consistent with RFC 8490, DNS Stateful Operations, the underlying technology used by draft-ietf-dnssd-push.

I believe it was actually you who suggested using TLS close_notify:

> From: David Schinazi <>
> Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20
> Date: 2 July 2019 at 12:36:09 PDT
> To: Tom Pusateri <>
> Cc: Robert Sparks <>,, DNSSD <>
> Resent-From:
> Resent-To:,,,,,, Tim Wicinski <>,
> Hi Tom,
> If the protocol is restricted to TLS over TCP, it should send a TLS close_notify, not a TCP RST.
> TLS close_notify is cryptographically guaranteed to originate from the peer,
> whereas TCP RST can be injected by an on-path entity to cause truncation attacks.
> Thanks,
> David

I suspect we have a miscommunication going on here.

Robert Sparks, in his Genart review, said:

> Page 23, top of page: Since section 4 restricts this protocol to TLS over TCP,
> the "(or equivalent for other protocols)" phrase should be removed.

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.

Stuart Cheshire