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

[Stuart Cheshire <[e-mail]>]

On 2 Jul 2019, at 12:36, David Schinazi <[e-mail]> 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.

<https://tools.ietf.org/html/rfc8446#section-6.2>

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