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

[Eric Rescorla <[e-mail]>]

On Sun, Jul 14, 2019 at 2:05 PM Michael Richardson <[e-mail]>
wrote:

>
> Ted Lemon <[e-mail]> wrote:
>     > 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.
>
> I'm unaware of TCP stacks that can turn off RSTs on a per-socket basis.
> Is this commonly available now and I'm just ignorant of it?
>
> I imagine that is the only way the application could inform the kernel that
> TLS is active.
>
> I guess a filter could drop RSTs to port 853, and assume it's always TLS.
>

I'm not sure how much this would help: if the attacker can inject an invalid
data segment full of random data, then this will likely lead to TLS
connection
failure (i.e., you'll be able to detect the problem but it's not
recoverable).
I'm not sufficiently up to date on the state of TCP injection attacks to
know
whether off-path RST attacks are significantly harder than off-path data
injection
attacks (obviously, on-path attacks are straightforward in both cases).


> Securing TCP against fake RSTs is something the TCP-AO was designed to do.
> AFAIK, we never defined a way to key TCP-AO from TLS.
>

No, we did not. It's theoretically straightforward, but you know what they
say
about the difference between theory and practice. In this particular case,
given the low level of deployment, it seems like it might be easier to just
move to QUIC.

-Ekr


> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>