Re: [Tsv-art] [MBONED] Tsvart last call review of draft-ietf-mboned-driad-amt-discovery-09

["Holland, Jake" <[e-mail]>]

Hi Bernard,

The follow-ups with text below with [JH].

From: Bernard Aboba <[e-mail]>
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