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

[Ted Lemon <[e-mail]>]

On Mar 2, 2020, at 10:54 AM, Carsten Bormann <[e-mail]> wrote:
> 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).

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

Yup.

>> If the client is configured to register at any RD in the current domain,
>> it'd receive a
>> 
>> _core-rd-dtls._udp.example.com <http://udp.example.com/> IN SRV 1 1 5683 rd1.example.com <http://rd1.example.com/>
>> 
>> When it connects, the server would present a certificate for
>> rd1.example.com <http://rd1.example.com/>
> 
> Would it?  It might be using PSK.

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.

>> without any indication that it's a legitimate
>> _core-rd-dtls._udp.example.com <http://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).

Yup.

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

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