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

[Carsten Bormann <[e-mail]>]

On 2020-03-02, at 15:55, Christian Amsüss <[e-mail]> wrote:
> 
> 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.

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.)

> 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

Would it?  It might be using PSK.

> without any indication that it's a legitimate
> _core-rd-dtls._udp.example.com.

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).

> 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.)

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