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

[David Schinazi <[e-mail]>]

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.

David

On Mon, Jul 8, 2019 at 3:53 PM Stuart Cheshire <[e-mail]> wrote:

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