On Tue, Jul 12, 2022, 12:52 AM Joseph Salowey <joe@xxxxxxxxxxx> wrote:
Thanks for the quick reply, comments below:On Sat, Jul 9, 2022 at 5:33 AM Ben Schwartz <bemasc@xxxxxxxxxx> wrote:Hi Joe,On Fri, Jul 8, 2022 at 8:05 PM Joseph Salowey via Datatracker <noreply@xxxxxxxx> wrote:- Section 8.1.2 - good description of this problem, it seems like some of this
should have been discussed in the doh document, but I couldn't find any. If
there is relevant considerations in the doh document then you should reference
them here.This topic is not addressed in RFC 8484 because that standard assumes that the URI template is configured from a single source, so all its components are equally authentic. The strange thing here is that the hostname comes via a (unspecified) trusted channel, but the port and path do not.[Joe] I see, so this adds some attack vector that was not anticipated in 8484It seems that the recommendation "To mitigate redirection attacks,
a client of this SVCB mapping MUST NOT identify or authenticate itself when
performing DNS queries, except to servers that it specifically knows are not
vulnerable to such attacks." would be difficult to implement since its not
clear how the client gets this information and really should be a consideration
for the server implementations/deployments that require authentication.How about "... except under private arrangement with a server operator who has made sure that there are no such vulnerable services on $HOSTNAME"?[Joe] Could we say something like "the server operator should make sure that there are no such vulnerable services on $HOSTNAME before publishing an SVCB mapping"
It's not clear to me that this would help, because this attacker can forge a SVCB record even for origins that don't publish their own record. In the extreme case, the origin might not operate a DNS service at all!
It seems the server should really take steps to prevent this if possible.
I can't think of a way to do this without adding a new requirement to all DNS servers that are identified by a hostname. As a practical matter I suppose that would be fine, but in principle it seems like poor form to add requirements to existing deployed systems.
Having the client also verify this to the best of their ability is also a good idea.I'm
not really sure what to do about this except as a consideration for a revision
of DoH.I don't think RFC 8484 has a problem of this kind, because an adversary cannot alter any portion of the URI template (unless it controls the whole template). (There is still the ALPACA attack, but that is not specific to DoH.)[Joe] yea, thanks for clarifying
<<attachment: smime.p7s>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
