> I think Michael's point was that *mixing* solutions while running insecurely
> is a bad idea, since it increases the attack surface. (That's also why DULL
> itself only allows a small subset of GRASP operations.)
Ok, agreed. Indeed I was thinking of deployments without DULL/GRASP where
constrained-BRSKI is used. Then there are other methods of Join Proxy discovery
as indicated in the join-proxy draft, e.g. by 15.4 beacons or MLE messages
which I'm most familiar with.
But CoAP discovery or DNS-SD could be used there in case there's no DULL/GRASP
support intended.
The Registrar can be discovered by the Join Proxy in different ways and one of
these ways may be DNS-SD.
Esko
-----Original Message-----
From: Brian E Carpenter <brian.e.carpen...@gmail.com>
Sent: Friday, December 3, 2021 20:32
To: Esko Dijk <esko.d...@iotconsultancy.nl>; Michael Richardson
<mcr+i...@sandelman.ca>
Cc: anima@ietf.org
Subject: Re: [Anima] Constrained-join-proxy: use of DNS-SD discovery of a Join
Proxy
On 04-Dec-21 02:54, Esko Dijk wrote:
> Thanks for the input. In constrained-join-proxy-06 both discovery types are
> mentioned in section 5.1 and the sentence on DNS-SD actually refers to
> service discovery in general (of either a Join Proxy or a Registrar's
> join-port for JPY protocol).
> So an implementation could still decide to only allow discovery of the
> Registrar's join-port and not discovery of the Join Proxy (unprotected/"DULL"
> side).
>
> Maybe good to know why mDNS/DNS-SD discovery is a bad idea on the unprotected
> side?
I think Michael's point was that *mixing* solutions while running insecurely
is a bad idea, since it increases the attack surface. (That's also why DULL
itself only allows a small subset of GRASP operations.)
Brian
> Since we also do e.g. CoAP discovery on the unprotected side. (Is that a bad
> idea as well?)
>
> Regards
> Esko
>
> -----Original Message-----
> From: Anima <anima-boun...@ietf.org> On Behalf Of Brian E Carpenter
> Sent: Thursday, December 2, 2021 20:23
> To: Michael Richardson <mcr+i...@sandelman.ca>
> Cc: anima@ietf.org
> Subject: Re: [Anima] Constrained-join-proxy: use of DNS-SD discovery of a
> Join Proxy
>
> On 03-Dec-21 07:01, Michael Richardson wrote:
>>
>> * While reviewing latest updates; one other issue came up: the draft
>> (re
>> * latest in Github) currently mentions DNS-SD as a means for a Pledge
>> to
>> * discover a Join Proxy.
>>
>> please note that this discovery occurs on the untrusted ("DULL") side.
>>
>> Brian E Carpenter <brian.e.carpen...@gmail.com> wrote:
>>> I think there's another reason for deferring it. We have a pending proposal
>>> in draft-eckert-anima-grasp-dnssd for how DNS-SD will integrate in an
>>> autonomic environment. It seems wise to have more clarity about that before
>>> defining how DNS-SD works for a Join Proxy. The two things may be
>>> completely orthogonal, but that requires a little thought.
>>
>> I don't think we can assume any GRASP or DNS-SD interoperation on the
>> untrusted side. It's just a bad idea.
>
> Yes. Probably that merits a MUST NOT in the Security Considerations of
> draft-eckert-anima-grasp-dnssd.
>
> Brian
>
>>
>> As for the Join Proxy discovering the Registrar, that's a different question.
>> We defined GRASP already for that. If we have a DNS-SD method as well, then
>> that would just be an additional method inside an ACP.
>>
>> --
>> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>>
>>
>>
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
