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

Stuart Cheshire <> Mon, 08 July 2019 22:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C853712037D; Mon, 8 Jul 2019 15:53:56 -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 V3vUZYTt_Uyx; Mon, 8 Jul 2019 15:53:53 -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 1B400120320; Mon, 8 Jul 2019 15:53:53 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x68Mptwq005298; Mon, 8 Jul 2019 15:53:50 -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=d40JHvGkWL2LZ/CdN2qMzMbPSMWWWzfhLUc8IUmo/X0=; b=Zi9MpvElnsTmMXmEpg+DQSj+7qfUZG4wWaxAD9mYcrDYWv9RLz5ieS7/EAlrI3zvcQ7r inajYdUEWxshgM3wJfYdCKenUdHTZ6zH0mLXP/rjVuipIW9iyjZlLfCj0mQuHvwlqUI/ kT0eVb7CP9CSr7WGCvrRJAdtxCW7jE+tFS1s3WCstVG79EA1zS0MZi+f4F5knXRnwkzb +sBdhR1qTYfrPxxMHsatJlqqY38MI71MSOvIShC4c/s+eKeQYrg/qiaikexLLq096k6Z oNiVc7hScsNJwPCRwZXgPUauCCkYBh4C7nKWLwqDfsECxB4vcpA3mfsm8nMvx98Ij53A Xw==
Received: from ( []) by with ESMTP id 2tkbvk4pfv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 08 Jul 2019 15:53:50 -0700
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built May 7 2019)) with ESMTPS id <>; Mon, 08 Jul 2019 15:53:50 -0700 (PDT)
Received: from by (Oracle Communications Messaging Server 64bit (built May 7 2019)) id <>; Mon, 08 Jul 2019 15:53:50 -0700 (PDT)
X-Va-T-CD: 10a534a1686abdccb129dd18c18ba03f
X-Va-E-CD: 3c579badc8061719d024feec5a8178fb
X-Va-R-CD: dac62b87d893430a0308504ef8763cad
X-Va-CD: 0
X-Va-ID: ff7f07e5-ca13-400e-94d9-ecf5596c31e7
X-V-T-CD: 10a534a1686abdccb129dd18c18ba03f
X-V-E-CD: 3c579badc8061719d024feec5a8178fb
X-V-R-CD: dac62b87d893430a0308504ef8763cad
X-V-CD: 0
X-V-ID: 97fc82e5-31cc-416e-85fb-ec65b8ce3980
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-08_09:,, signatures=0
Received: from [] (unknown []) by (Oracle Communications Messaging Server 64bit (built May 7 2019)) with ESMTPSA id <>; Mon, 08 Jul 2019 15:53:33 -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: Mon, 08 Jul 2019 15:53:32 -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-08_09:, , 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: Mon, 08 Jul 2019 22:54:04 -0000

On 2 Jul 2019, at 12:36, David Schinazi <> wrote:

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

In TCP we use FIN for a graceful close, and RST for an abortive close. The former is normal operation; the latter means your code has a bug you need to fix.

Is there an appropriate equivalent in TLS? It would be good to differentiate normal operation from a fatal protocol error that causes a forcible termination.

I see in the TLS 1.3 spec, RFC 8446, Section 6.2. “Error Alerts” says:

   Whenever an implementation encounters a fatal error condition, it
   SHOULD send an appropriate fatal alert and MUST close the connection
   without sending or receiving any additional data.


Are any of these error alerts appropriate to perform this abortive disconnect, like perhaps the decode_error code?

   decode_error:  A message could not be decoded because some field was
      out of the specified range or the length of the message was
      incorrect.  This alert is used for errors where the message does
      not conform to the formal protocol syntax.  This alert should
      never be observed in communication between proper implementations,
      except when messages were corrupted in the network.

Or are these TLS error alerts reserved for TLS-layer error conditions?

Stuart Cheshire