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

[David Schinazi <[e-mail]>]

Thanks Stuart, that makes sense to me - I hadn't loaded the entire context
back into memory... Apologies.

Basically a "graceful" close should always use a TLS close_notify, but any
catastrophic failure can use TCP RST.

David

On Tue, Jul 9, 2019 at 7:22 PM Stuart Cheshire <[e-mail]> wrote:

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