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

[Tom Pusateri <[e-mail]>]

I pointed out earlier that now that we have a RETRY DELAY TLV in DNS Stateful Operations, we can do better than just a TCP RST by not only signaling that a fatal error occurred but also, inform the client not to try reconnecting for a long time.

This means we would always close with a TLS close_notify and if a fatal error occurs, we set the RETRY DELAY. This would keep the broken client from connecting right away again and then following the same error path.

So we should discuss this more before restoring the old behavior.

Tom

> On Jul 10, 2019, at 1:32 PM, David Schinazi <[e-mail]> wrote:
> 
> 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
>>