Hi Bernard, The follow-ups with text below with [JH]. From: Bernard Aboba <bernard.aboba@xxxxxxxxx> Date: 2019-12-03 at 14:11 > [BA] I raised the question because the value of DoT or DoH wasn't > clear to me in this context. Based on the above, it might make > sense to focus on DNSSEC and consider leaving out DoT or DoH. [JH] I believe I cribbed parts of this paragraph from Section 4 of RFC 4025, which has a similar requirement: https://tools.ietf.org/html/rfc4025#section-4 As I understand it, the ideal is to secure an end-to-end authentic RR, and the choices are either DNSSEC, or where DNSSEC is unavailable, a secure connection to a trusted resolver. I was thinking DoT and DoH were natural additions to the TSIG and SIG(0) options, so I think it makes sense either to include them or to cut TSIG and SIG(0) (as well as the "secure connection to a local server") and generalize to "secure RR transfer from a trusted resolver", removing the references. I thought a pointer to the existing options for these was a useful addition (following the example of RFC 4025), so I'm modestly inclined to leave the mentions in, with a slight rephrase to better explain how it relies on the trust relationship. So how about this? OLD: There must be a trust relationship between the end consumer of this resource record and the DNS server. This relationship may be end-to- end DNSSEC validation, a TSIG [RFC2845] or SIG(0) [RFC2931] channel to another secure source, a secure local channel on the host, DNS over TLS [RFC7858] or HTTPS [RFC8484], or some other secure mechanism. NEW: There must be a trust relationship between the end consumer of this resource record and the DNS server. This relationship may be end-to- end DNSSEC validation, or a secure connection to a trusted DNS server that provides end-to-end safety, to prevent record-spoofing of the response from the trusted server. The connection to the trusted server can use any secure channel, such as with a TSIG [RFC2845] or SIG(0) [RFC2931] channel, a secure local channel on the host, DNS over TLS [RFC7858], DNS over HTTPS [RFC8484], or some other mechanism that provides authentication of the RR. I've provisionally made the above change, but I really don't have a strong preference, so I can easily be talked into removing the secure connection pointers completely, like so: NEW(2nd alternative): There must be a trust relationship between the end consumer of this resource record and the DNS server. This relationship may be end-to- end DNSSEC validation, or a secure connection to a trusted DNS server. Please let me know about any opinions here, I'm happy with either, but leaning toward the first. >> ... <explanation about utility of the new RR> ... > [BA] Thanks for the clarification. Might be useful to add some of the > above explanation to the document. [JH] Here's a proposed new paragraph added to the bottom of section 2.3.1: Note that the DNS-SD service is not source-specific, so even though several methods of finding a more local source of multicast traffic connectivity are preferred where available to using a relay provided by an AMTRELAY RR, a gateway further upstream would still be using the AMTRELAY RR unless the upstream network has a peering or direct connectivity that provides an alternative end-to-end multicast transport path for the (S,G)'s traffic. Please let me know if that covers your concerns here or if you have any suggestions to improve it, and I'll post the new version. Thanks for the suggestions! Best regards, Jake -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
