Re: [dnssd] Roman Danyliw's No Objection on draft-ietf-dnssd-srp-23: (with COMMENT)

[Ted Lemon <[e-mail]>]

Roman, thanks for the IESG review and comment. Sorry for the long delay. :]

On Mon, Aug 21, 2023 at 2:17 PM Roman Danyliw via Datatracker <
[e-mail]> wrote:

> Thank you to Joey Salazar for the SECDIR review.
>

Yes indeed!

Per this earlier comment:
>
> > ** Section 1.
> >   So we can only publish information that we feel safe in publishing
> >   even though we do not have any basis for trusting the requestor.
> >
> > What is the basis of considering particular information “safe”?
>
> I was indeed reacting to the word "safe" as noted here:
> https://mailarchive.ietf.org/arch/msg/dnssd/tjfqY9HYNsFUqJCR0VfJhHBEvsY/.
> The
> found the explanation in this thread illuminating and these would have been
> good words to include in the document.
>

This is what we have in the document now:

      <t>
The reason for this is precisely that we have not established trust. So we
can only publish information that we feel safe in
publishing even though we do not have any basis for trusting the requestor.
We reason that mDNS <xref target="RFC6762"/>
allows arbitrary hosts on a single IP link to advertise services <xref
target="RFC6763"/>, relying on whatever service is
advertised to provide authentication as a part of its protocol rather than
in the service advertisement.</t>

      <t>
This is considered reasonably safe because it requires physical presence on
the network in order to advertise. An off-network
mDNS attack is simply not possible. Our goal with this specification is to
impose similar constraints. Because of this you will
see in <xref target="add_validation"/> that a very restricted set of
records with a very restricted set of relationships are
allowed. You will also see in <xref target="source_validation"/> that we
give advice on how to prevent off-network attacks.</t>

      <t>
This leads us to the disappointing observation that this protocol is not a
mechanism for adding arbitrary information to
DNS zones. We have not evaluated the security properties of adding, for
example, an SOA record, an MX record, or a CNAME
record, and so these are forbidden. A future protocol specification might
include analyses for other records, and extend
the set of records that can be registered here. Or it might require
establishment of trust, and add an authorization model
to the authentication model we now have. But this is work for a future
document.</t>

I think the third paragraph addresses what /information/ we consider safe,
as opposed to in what context such information could be safely registered.
I looked at the message you quoted above, and didn't find anything
mentioned there that isn't addressed in this section of the introduction. I
don't think we need to include this in the specification portion of the
document—the point in the introduction is simply to explain why service
registration instructions are constrained to just those few records that we
explicitly allow there.