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

[Stuart Cheshire <[e-mail]>]

On 8 Jul 2019, at 16:05, David Schinazi <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]>
> Cc: Robert Sparks <[e-mail]>, [e-mail], DNSSD <[e-mail]>
> Resent-From: [e-mail]
> Resent-To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], Tim Wicinski <[e-mail]>, [e-mail]
> 
> 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