Subject: Re: [core] DNS-SD service types for CoRE-RD (Re: AD review of draft-ietf-core-resource-directory-23)

From: Christian Amsüss <[email-masked]>
Date: Mon, 2 Mar 2020 15:55:39 +0100

Hello group,
hello Carsten,

On Mon, Dec 09, 2019 at 09:34:29PM +0100, Carsten Bormann wrote:
> In the meeting, I gave the three examples _core-rd._udp,
> _core-rd-tls._udp, and _core-rd._tcp — noting that while core-rd is a
> proper RD service type, core-rd-tls isn’t.  To cover the six
> transports we have for CoAP today (coap, coaps, coap+tcp, coaps+tcp,
> coap+ws, coaps+ws), we would need four service types on top of _tcp
> and could use two of them over _udp?

Do we have a meaningful way to deal with (D)TLS in DNS-SD at all? I'm
only superficially familiar with the verification steps done on the host
name, but as I understand, TLS typically authenticates the host name.

If the client is configured to register at any RD in the current domain,
it'd receive a

_core-rd-dtls._udp.example.com IN SRV 1 1 5683 rd1.example.com

When it connects, the server would present a certificate for
rd1.example.com without any indication that it's a legitimate
_core-rd-dtls._udp.example.com.

Is there a document that bridges that gap in a usable manner that we can
point to for security considerations? Otherwise I'd rather leave the
TLSs out of here. (Alternatively, we could describe them as opportunistic
encryption.)

Kind regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Mar 2020 10:36:24 -0500

> name, but as I understand, TLS typically authenticates the host name.

The first question you should ask is, what are you trying to protect by using DTLS.  Until you answer that question, you’re not going to make any progress.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 2 Mar 2020 16:54:27 +0100

> name, but as I understand, TLS typically authenticates the host name.

One assumption that is used in many TLS-based applications is that TLS is used to authenticate the server as the holder of the domain name that the client specified upon connection setup (e.g., after taking that domain name out of an https:// URI as the only information that is available for authorizing that server).
(Since DNS-SD is about domain names, this assumption might seem more appropriate for DNS-SD based usage than it is in other ways of using CoAP, but then DNS-SD may just be in use for an initial RD discovery phase.)

> rd1.example.com

Would it?  It might be using PSK.

> without any indication that it's a legitimate

There must be another source of that authorization (as a resource directory that this client is authorized to use — not with respect to the resource directory allowing access, but with respect to the overseeing principal of the client allowing that to rely on using it).

> TLSs out of here. (Alternatively, we could describe them as opportunistic

This situation is as open to different authorization strategies as any other use of CoAPS is, so I don’t see why we need to make this a special case.

Grüße, Carsten

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Mar 2020 11:21:39 -0500

> One assumption that is used in many TLS-based applications is that TLS is used to authenticate the server as the holder of the domain name that the client specified upon connection setup (e.g., aft…

That’s what DNSSEC is for, so you definitely shouldn’t use it exactly this way.   The correct way to do something like this, if you want to, is to trust the “AD” bit returned by the resolver.  In order to do this, you would want to use DTLS to validate your trust relationship with the resolver.  You could also use TSIG or SIG(0) for that, however, at a substantially lower cost.   Although it might be worth it to use DTLS just because it’s one less hunk of code to include if you’re already using DTLS for something else.

> (Since DNS-SD is about domain names, this assumption might seem more appropriate for DNS-SD based usage than it is in other ways of using CoAP, but then DNS-SD may just be in use for an initial RD…

Yup.

>> _core-rd-dtls._udp.example.com <http://udp.example.com/> IN SRV 1 1 5683 rd1.example.com <http://rd1.example.com/>
>> 
>> rd1.example.com <http://rd1.example.com/>
> 

You have a choice: you can either use a PSK, or you can use PKI+configured trust relationship based on name.   The trust relationship is implicit with PSK.   PSK should still be asymmetric, so that you don’t create a fertile ground for attacks.

>> _core-rd-dtls._udp.example.com <http://udp.example.com/>.
> 

Yup.

> This situation is as open to different authorization strategies as any other use of CoAPS is, so I don’t see why we need to make this a special case.

While this is true in principle, I don’t think we want a million different authorization strategies to choose from.

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 9 Mar 2020 10:06:19 +0100

Hello Ted, Carsten and group,

thanks for your input; I take from it that DNS-SD discovered secure RD
access is realistic, and that while there are several ways to use it,
those are not specific to RD and thus we don't have specific security
guidance.

For the common usage of RD that I personally expect, UDP will be the
predominant usage pattern, and the other protocols could still be
entered into the registry when actually needed -- that would make the
whole thing simpler here as it's only a single new type. Text proposals
for both versions (coap/coaps/coap+tcp/coaps+tcp[1,2,3] and
coap-only[4,5,6]) are currently in the editors' copy branches, diffs and
issue tracker.

Given that what was previously discussed in the WG all points to
many-services, I'll merge and submit the four-protocol variety this
evening before cut-off, but if there are seconds for the argument for
simplicity in limited initial choice (with the option to extend without
RFC through IANA registration), I'd be happy to go with that.

Kind regards
Christian

[1]: https://core-wg.github.io/resource-directory/dnssd-moreprotos/draft-ietf-core-resource-directory.html
[2]: https://github.com/core-wg/resource-directory/pull/230/files
[3]: https://github.com/core-wg/resource-directory/pull/230
[4]: https://core-wg.github.io/resource-directory/dnssd-nomoreprotos/draft-ietf-core-resource-directory.html
[5]: https://github.com/core-wg/resource-directory/pull/231/files
[6]: https://github.com/core-wg/resource-directory/pull/231

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 25 Mar 2020 16:30:32 +0000

Dear CORE WG participants,

This is just a quick followup on my AD review. There were a couple of my 
comments that I don't think were addressed in -24. I would appreciate 
them being addressed or at least replied to:

On 04/11/2019 17:06, Alexey Melnikov wrote:
> Hi,
>
> My apologies for the delay in reviewing this document:
>
   [snip]
>
> In 5.3, 1st para:
>
>
>    This section describes how the registering endpoint can maintain the
>    registrations that it created.  The registering endpoint can be the
>    registrant-ep or the CT.  An endpoint SHOULD NOT use this interface
>
> Why SHOULD NOT (instead of MUST NOT) and how is this enforced?
>
>    for registrations that it did not create.  The registrations are
>    resources of the RD. 
  [snip]
> At the end of section 9.3:
>    It is expected that the registry will receive between 5 and 50 
> registrations in total over the next years.
>
> This will not age well! Maybe remove this text from the document and 
> add it to the spherding write-up?

Best Regards,

Alexey