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

[Eric Rescorla <[e-mail]>]

On Thu, Jul 11, 2019 at 2:44 PM David Schinazi <[e-mail]>
wrote:

> To reiterate my earlier point, TLS close_notify DOES NOT protect against
> an attacker closing the connection by sending a FIN or RST.
>

Just to clarify: it allows the receiver to distinguish between closes which
were initiated by the peer and those which were not


The benefit of close_notify is to protect against truncation attacks: if an
> attacker sends a FIN or RST in the middle of a stream,
> the recipient application should ignore the current message instead of
> considering it complete.
> This is important for protocols such as HTTP/0.9 that rely on the TCP FIN
> instead of using prefixed lengths.
> Given that DSO messages contain a prefixed length, making sure
> implementations do not act on partial messages is sufficient to prevent
> truncation attacks.
> If my understanding is correct, DNS-PUSH does not get ANY security
> benefits from close_notify.
>

Well, maybe. You could, for instance, log an error if a finished was
received without a close_notify.

-Ekr


> When a critical error occurs, a TCP RST should cause the other side to
> tear down state more aggressively than a close_notify, which is what we
> want.
>



> I'd recommend using close_notify for gracefully closes, and TCP RST for
> any critical failures.
>
> I agree with Ted that if an implementation is broken it's best to have it
> fail very visibly.
>
> David
>
> On Thu, Jul 11, 2019 at 11:20 AM Tom Pusateri <[e-mail]> wrote:
>
>> If a client implements PUSH, it implements DSO which means it implements
>> KEEPALIVE and RETRY DELAY.
>>
>> That doesn’t mean it will honor every part and it might retry before the
>> delay expires.
>>
>> But the server sent the retry delay and knows the timeout value and so
>> the server can filter this client for that period of time regardless of
>> whether the client honors it or not. In fact, a server SHOULD do the
>> filtering because the RETRY DELAY is really saying, I’m not going to listen
>> to you until after this timeout.
>>
>> Also, even if the client closes because of an error, that doesn’t
>> preclude it from using TLS session resumption for the next subscription.
>>
>> So I’m in favor of always using close_notify and sending a RETRY DELAY
>> for critical errors when needed.
>>
>> But I think it would be helpful to outline the actual errors that could
>> occur on either end and verify this works in every case. Sending as much
>> information to the other side as possible is helpful for determining bugs.
>> TCP RST signaling doesn’t convey much information.
>>
>> Tom
>>
>> On Jul 11, 2019, at 1:19 PM, Ted Lemon <[e-mail]> wrote:
>>
>> On Jul 9, 2019, at 10:22 PM, Stuart Cheshire <
>> cheshire=[e-mail]> wrote:
>>
>> 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.
>>
>>
>> To add some further nuance from a discussion that Stuart and I had today
>> on this, there are actually several different cases where connection closes
>> are done, and how they should be done is something we should talk about.
>>
>> I think in all cases where the client is closing the connection, there’s
>> a case to be made that we *don’t* want to use close_notify.   It’s true
>> that an attacker can kill our DNS Push connection in this case by forging
>> an RST to the server.   We should discuss whether this is a serious concern
>> that we need to take into account.   If it is, then using close_notify
>> would protect against this iff the server ignores TCP RSTs for active TLS
>> sessions.
>>
>> But the main argument for using close_notify in this case is that we want
>> to be able to resume.   This will not be the case if the client closed the
>> connection because of a protocol error.   It will be the case when the
>> client is closing the connection due to inactivity.
>>
>> There is a case where the server closes the connection when the client
>> sends a duplicate subscribe.   That’s because this is a protocol error: the
>> client is broken, and cannot be expected to take corrective action.   Then
>> the question is, do we close the connection down with a retry-delay to make
>> the client go away, or do we just send an RST?
>>
>> Argument in favor of sending retry-delay:
>>
>>    - if the client implements it, it will shut up for a while.
>>
>>
>> Arguments against:
>>
>>    - If the client doesn’t implement it, it won’t shut up, so we haven’t
>>    gained anything
>>    - Making things “sort of work” when the client is broken isn’t all
>>    that helpful—we actually want the behavior in this case to be
>>    dysfunctional, so that it is noticed and fixed.
>>
>>
>> I think that the working group should consider these issues and come to a
>> consensus.
>>
>> My own personal opinion is that we should always do close_notify, because
>> if we can assume this, then an attacker can’t kill the connection by
>> sending an RST, if that behavior is implemented in the TLS/TCP stack.   My
>> one doubt about this is that if we are going through a NAT, will the NAT
>> drop its mapping when it sees the RST?   If so, then close_notify doesn’t
>> protect against this attack for a majority of current users.   It still
>> might be worth doing for IPv6, of course.
>>
>> As to whether we should use retry-delay, I have really mixed feelings
>> about this.   I want implementations to be visibly broken when they are
>> broken, but I don’t want to have to operate a server that has to deal with
>> broken clients.   The question is whether forcibly disconnecting will
>> actually cause implementors to take action, or whether it will not be
>> noticed and contribute to dysfunction.
>>
>> My personal experience is that breaking badly is actually conducive to
>> improvement, so that’s the direction I’m leaning at the moment.
>>
>> _______________________________________________
>> dnssd mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnssd
>>
>>