Re: [DNSOP] DNSOP: question about hardening "something like mDNS" against attacks

[Toerless Eckert <[e-mail]>]

On Mon, Oct 26, 2020 at 04:39:10PM -0400, Ted Lemon wrote:
> On Oct 26, 2020, at 4:14 PM, Toerless Eckert <[e-mail]> wrote:
> > And the question from the AD was what could be done. So, do you have any
> > implemention suggestion ? Are there any sugestions for mDNS ?
> 
> There are no simple mitigations. If there were, they would already be in the protocol.

And with protocol you also include local state machineries such as the
heuristic i described ? (sorry, just wanting to make sure).

> > Btw: I do agree that for most use of mDNS as it is relying on dynamic ports,
> > my suggestion would create an undesired trend of allocating static port numbers.
> > This is also true for GRASP in general, but for the specific use-cases
> > in mind in my text, which are really inside-network infra protocols, the argument could be
> > made that static port allocation was indeed well feasible (as we're talking about a
> > very small number here) . But we had not done it because we hadn't vetted the benefits
> > of doing such a port allocation.
> 
> If it???s a multicast discovery protocol with no authentication, then constraining the set of allowed ports just means that the node that???s attacking you has to be able to listen on that port, which it likely can. So I think this reduces function without increasing hardening.

Elimination of the port number as an announced service element (and instead assuming
 there is a well-known port) eliminates the amplified attack of sending such announcements
with a sweep of port numbers and therefore condemning the consuming client to
try out all those port numbers.

> What actually hardens mDNS is that it???s a link-local protocol.
> It doesn???t work across links.

I am not aware that the solutions to extend mDNS across multiple hops
would be any more hardened necessarily. But water under the bridge.

> This limits the attack surface.
> But there???s no way to eliminate the attack surface.
> If I were in Ben???s shoes, I???d be asking you to change the protocol
> to support authentication and ToFU as a hardening strategy,
> with some better trust establishment mechanism as future work based
> on the existing presence of crypto signatures.
> But the current consensus of the IETF is apparently that ADs aren???t allowed to insist on things like that. :(

Well, it would singling out new work with a humunguously higher bar to jump
over than widely used protocols even including similar DoS attack in
DAAD if i am not mistaken (given how mDNS isn't all that prevalent).
Or just look at how convoluted the work was to attempt making process
with neighbor discovery in routing protocols.

Actually for our specific use-case i would like to propose an authenticated
method, alas there is no pre-established knowledge of the cert of the
neighbor, so it might have to include the whole bloody cert in a packet to authenticte
the packet, and that might be problematic size-wise. Maybe payload-layer
segmented multicasting *sigh*. Discussion for another time.

-- 
---
[e-mail]