Add security considerations on potentially unencyrypted upstream DNS

[miri64]

This fixes #35. See also https://mailarchive.ietf.org/arch/msg/core/warTSPRBXE4OrOam_TeIvRZFHUc/ ff.

@EskoDijk does this fit what you had in mind?

[EskoDijk]

@miri64 I think there could be also confidentiality and integrity without a shared security context?
For example, the DoC server uses a 2nd (new) security relation established by TLS to talk to the DNS server. This context isn't shared with the DoC client but still there is security. (I'm not counting here any attacker present on the DoC Server itself!)
If so then the text needs to be updated to reflect this.

I have some trouble understanding "unless the security context is with yet another party": if this refers to an OSCORE context, then it's unclear how a DNS server would use OSCORE given it's not CoAP. So that seem unpractical.
And if it's DTLS; it's unclear how e.g. a TLS DNS server could share that same context. Normally it's established independently by the handshake.

In general besides confidentiality, integrity could also be mentioned. (With DNS over UDP the response may get modified by an on-path attacker.)

Do we also need to say that the security of the 2nd leg is out of scope of this document? (Although we could recommend that it's always enabled by default?)

[miri64]

@miri64 I think there could be also confidentiality and integrity without a shared security context?
For example, the DoC server uses a 2nd (new) security relation established by TLS to talk to the DNS server. This context isn't shared with the DoC client but still there is security. (I'm not counting here any attacker present on the DoC Server itself!)
If so then the text needs to be updated to reflect this.

True, that's why I used the wording "may communicate unencrypted with the upstream DNS infrastructure". If this needs more emphasis, I can reword.

I have some trouble understanding "unless the security context is with yet another party": if this refers to an OSCORE context, then it's unclear how a DNS server would use OSCORE given it's not CoAP.

It was referring to OSCORE, in the sense that the DoC server acts as a proxy in this case.

In general besides confidentiality, integrity could also be mentioned. (With DNS over UDP the response may get modified by an on-path attacker.)

Yes, but since there is also DNSSEC, integrity is a little bit tricky to word here. In general, I would not recommend DNSSEC in constrained environments, but it could be used to ensure at least integrity from client to upstream. I agree, we should mention integrity, but we should be careful how we do it and what we recommend to ensure it.

Do we also need to say that the security of the 2nd leg is out of scope of this document? (Although we could recommend that it's always enabled by default?)

It is certainly not in the control of a DoC deployment. Recommendations always help, but I would make that non-normative.

[miri64]

@EskoDijk I added some words on DNSSEC and integrity. Can you have another look?