Hiya,
On 20/03/2026 02:40, tirumal reddy wrote:
Hi Stephen,
Thank you for the review. This is a good catch, we never imagined this
could result in automatic connection initiation, but thank you for bringing
it up.
That said, the concern is already partially addressed by the draft. Section
5.3 and the Security Considerations define a strict set of checks that must
pass before any field is acted upon, including transport security
verification, resolver authentication, and client security policy
evaluation. Only after all these checks pass is the information displayed
to the end-user. The "c" field contains contact URIs that require explicit
user interaction to initiate a connection.
On the registry expansion concern, the current registry intentionally
limits Contact URI schemes to sips, tel, and mailto; schemes that do not
result in automatic HTTP connections. Any future addition of https would
require IETF Review, providing the appropriate oversight to evaluate
exactly the risks you describe.
To make these guarantees more explicit, we will add the following text to
the Security Considerations:
Clients MUST NOT automatically initiate connections to URIs derived
from the EXTRA-TEXT field. Doing so could allow a resolver
to silently report client activity to third parties at scale, enable
DoS reflection attacks, or be used to frame a client. The restriction
Contact URI schemes to sips, tel, and mailto is intentional, as
these schemes do not result in automatic HTTP connections.
I think that's a good addition, thanks. But I'm still concerned that a stub resolver might use URL-displayjng libraries that emit such a signal in a way that a colluding observer might be able to leverage. What motivates this concern is work by a colleague (Doug Leith) and some of his students, e.g. [1] that shows that keyboard apps on mobile devices emit privacy-busting telemetry whenever they pop up. ISTM a stub resolver could be in a similar position to a keyboard app in this situation, so we could end up in an RFC 6919 "REALLY SHOULD NOT" situation, which'd seem like a bad outcome. That said, I've no concrete evidence that a stub trying to display the URLs here might in fact leak in this way. Has anyone tried to determine if that may be the case or not? Have there been any tests or trials that tried to figure that out? Has anyone tried to craft a bad-actor recursive that causes the stub to emit such signals? This concern, I think, overlaps to an extent with the one Lars expressed about displaying the information returned according to this spec. Cheers, S. [1] https://www.scss.tcd.ie/Doug.Leith/pubs/gboard_kamil.pdf
Cheers, -Tiru On Thu, 19 Mar 2026 at 19:36, Stephen Farrell <[email protected]> wrote:Apologies for being late responding to the WGLC. I (still) don't think this draft is a good idea. Reading -18 (quickly) just now I don't see any statement along the lines the a client MUST NOT initiate connections based on the content returned, which I think means this mechanism could provide a way to automatically, and at scale, report to "the authorities" that a query for the relevant DNS name was made, and from where. That could happen if: - a client parsing the JSON initiates a connection to any IP address derived from the response content - some client libraries might automatically do that if presented with strings that are to be interpreted as URIs - a change to the registry in 11.3 adding https would seem to make this much more likely as some clients would probably access the URL to offer a preview of the content or to pre-load the content I'd also worry that clients might anyway ignore the MUST that only sips/tel/mailto are to be supported for now. I note that clients can easily be induced to make such DNS queries via e.g. adverts or email content (if the text/html body part is rendered), so such connections could also be part of a DoS reflection attack, or used to "frame" a client. Overall, this just seems to much of a dangerous implement to me. Cheers, S. On 27/02/2026 12:26, Benno Overeinder via Datatracker wrote:This message starts a WG Last Call for: draft-ietf-dnsop-structured-dns-error-17 This Working Group Last Call ends on 2026-03-13 Abstract: DNS filtering is widely deployed for various reasons, including network security. However, filtered DNS responses lack structured information for end users to understand the reason for the filtering. Existing mechanisms to provide explanatory details to end users cause harm especially if the blocked DNS response is for HTTPS resources. This document updates RFC 8914 by signaling client support for structuring the EXTRA-TEXT field of the Extended DNS Error to provide details on the DNS filtering. Such details can be parsed by the client and displayed, logged, or used for other purposes. File can be retrieved from: Please review and indicate your support or objection to proceed with the publication of this document by replying to this email keeping[email protected]in copy. Objections should be explained and suggestions to resolve themarehighly appreciated. Authors, and WG participants in general, are reminded of the Intellectual Property Rights (IPR) disclosure obligations described in BCP 79 [1]. Appropriate IPR disclosures required for full conformance with theprovisionsof BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. Sanctions available for application to violators of IETF IPR Policy canbefound at [3]. Thank you. [1] https://datatracker.ietf.org/doc/bcp78/ [2] https://datatracker.ietf.org/doc/bcp79/ [3] https://datatracker.ietf.org/doc/rfc6701/ The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-structured-dns-error/ There is also an HTML version available at:https://www.ietf.org/archive/id/draft-ietf-dnsop-structured-dns-error-17.htmlA diff from the previous version is available at:https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-structured-dns-error-17_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
