Dear all, Thank you for the discussion of draft-bertoldi-regext-rdap-reliability-scoring-01 at IETF 126 in Vienna. Several of the sharpest questions were raised in the meeting chat and we did not get to them in the room, so we address them here, identify the central unresolved question, and set out what we intend to change. This is an individual, Experimental draft. We are not requesting adoption. 1. What we heard At the microphone: that the extension makes most sense when the assessment is published by a party other than the registry or registrar; that other RDAP extensions convey facts held in a registration database while this one conveys a value judgment; that the reliability of the score itself is unaddressed and that an assessed party needs a way to contest a result; that evidence of real interest would be needed before the working group considered taking on the work; and that at this stage it may be a solution in search of a problem. Mario Loffredo raised the concern we most want help with: that a security score risks being read as a rating, with reputational and commercial damage and legal disputes for the assessed party; that such a score can change quickly, so that a value today may be higher or lower tomorrow; and that publishing information about domains with a weak security posture may identify soft targets. He cited NIS2-related national guidance against disseminating information that could be useful to attackers. We think this is the hardest security and policy concern the draft raises, and Section 4 below sets out how we intend to reflect it in -02. We would also like to cite that guidance accurately, and would appreciate a pointer to the specific authority and document. In the chat, Gavin Brown asked why this belongs in RDAP if it is not run by a registry or registrar, and said he does not think it is work for REGEXT, with Jody Kolker agreeing. Jim Reid asked where else it would go. James Gould noted that the work would technically belong in REGEXT but perhaps not under the charter, and that RDAP can be served by providers other than registries and registrars. Richard Wilhelm argued that RDAP is preferable to a non-standard API for domain-oriented data. James Galvin observed that standardizing the extension puts it in REGEXT, and that it could otherwise be documented and registered with IANA as a proprietary extension. Gavin also asked whether a non-authoritative server would mirror and enrich the authoritative response or return something minimal, and how a client would learn about such a service; James Gould suggested a separate bootstrap might be needed, and Richard Wilhelm replied that it does not fit the bootstrap because such a server is not authoritative. We are grateful for all of it, including the objections. 2. Deployment model The draft describes no deployment model, and the chat made clear that this is the gap. Why RDAP. If assessment data of this kind are to be exposed at all, the likely alternative is each assessor publishing its own HTTP API with its own object model and query syntax. RDAP already provides domain lookup, entity object classes, a common response format and an extension mechanism that can be reused for this purpose. Minimal response, not mirroring. A non-authoritative assessment server should return only what is needed to bind the response to the object, plus the extension member, and must not be treated as authoritative for registration data. We would like to rule out the mirror-and-enrich pattern explicitly. Subject binding. For domains this is relatively straightforward: ldhName already provides the standard lookup key and /domain/<ldhName> works unchanged. For registrar entities it is not, and our presentation glossed over it. RFC 9082 defines entity lookup only as /entity/<handle>, with entity search by fn or handle, and a handle's syntax is specific to the registration provider. publicIds is a response structure, not a lookup key. Our inclination is that an assessment service should use its own service-local handle for /entity/<handle> lookups, with publicIds binding that local object to the assessed registrar, for example through the applicable IANA Registrar ID. We are not inclined to define a new lookup by IANA Registrar ID: that would turn this from a response extension into a query extension, with everything Section 2.4 of draft-ietf-regext-rdap-extensions entails, and we do not think it is warranted at this stage. We would rather be told we are wrong about that than not raise it. We would also welcome views on the corresponding binding for ccTLD registrars and for registrars with no IANA ID. The obvious weakness of the local handle model is that two assessors will use different handles for the same registrar, and publicIds supplies the binding only after the object has been retrieved. We would welcome guidance on whether RFC 8521 can be reused here. Object tagging can bootstrap an entity query when the client already has a tagged handle whose suffix identifies the RDAP service provider. It would not by itself allow a client to discover an assessor from an IANA Registrar ID, or bind scoreIssuer to that assessor. One possible profile would use the IANA Registrar ID as the local portion of the handle and the assessor's registered provider tag as its suffix, making the full handle derivable once the assessor is already known out-of-band. Is that a sound use of RFC 8521, given that the assessor would be authoritative for the assessment representation but not for the underlying registration data? Discovery of the endpoint. We agree this does not belong in the RFC 9224 bootstrap, since an assessment server is not authoritative for registration data. Where an issuer's endpoint is provisioned out-of-band together with the consumer's trust configuration for that issuer, no separate mechanism is needed. The draft would still need to explain how an endpoint is bound to a scoreIssuer identifier, which connects this to Section 3 below. We considered suggesting that an authoritative server point at an assessment service using a links member with the "related" relation, and are not proposing it. The "related" relation is already used for registry-to-registrar referrals. Reusing it here would require precise semantics, an expected media type and clear client processing rules; defining a new relation would require its registration. In either case, such a link could reasonably be read as an endorsement of the assessor. 3. Central unresolved protocol question: provenance and authenticity Our presentation implied that scoreScheme and scoreIssuer keep the judgment attributable to a party other than the RDAP server. That is the design intent, not a property the draft delivers, and we would rather say so than let it stand. scoreIssuer is a string. It records to whom a result is attributed. It does not demonstrate that the named issuer produced it, nor that the publisher relayed it unaltered. Where the assessor operates its own server, trust in the endpoint and in the issuer can reasonably coincide. Where a registry, registrar or other server republishes an assessor's result, the consumer must trust the publisher as an intermediary as well, and the protocol offers nothing with which to tell the two cases apart. We think this, rather than namespacing, is the central unresolved protocol question in the draft. Options we can see: leave authenticity out-of-band and say so explicitly; require scoreIssuer to be a globally unique and stable identifier, most likely a URI, rather than a local name such as the "example-assessor" in our examples; require evidenceUri to resolve to a resource under the issuer's control, which would provide a means of cross-checking the result but would not by itself authenticate the assessment carried in the RDAP response; or define a signed assertion. Each has costs and we have no settled preference. Relatedly, if all semantics live outside the protocol then scoreScheme must be stable. We are inclined to require that the semantics associated with a scheme identifier must not change incompatibly, and that an incompatible revision requires a new scheme identifier. 4. Planned changes in -02 A deployment model section covering the above. A more careful statement of what makes this extension different. Rather than claiming that all other RDAP extensions convey only database facts, which is too strong, we would say that unlike most registration data fields this extension carries evaluative metadata whose interpretation and consequences depend on an external methodology and issuer, creating materially different provenance, dispute, staleness and disclosure considerations. An expanded treatment of disclosure risk, covering perception as a rating, reputational and legal exposure of the assessed party, volatility, inferences drawn from absence, and the fact that a low score may itself be a targeting signal. Rather than recommending coarse-grained values as a general rule, which we now think premature, we would require the specification defining a scoreScheme to document a disclosure threat model, and to explain how data minimization is applied, including whether aggregation, coarse granularity, access control or delayed publication are appropriate. We would state the tension openly: the more actionable a signal is for defenders, the more useful it is to attackers, and this document cannot resolve that alone. Support for contestation and correction. Pointing at evidenceUri is not sufficient, since it may resolve to general documentation rather than a record of a specific result. We are considering an assessmentId, a status such as active, underReview, withdrawn or superseded, and a means of indicating supersession. The dispute process itself would remain a matter for the scheme. A changes section, which -01 lacks, and a corrected IANA section: the current one omits the Intended usage field required by the template in Section 8.1 of RFC 7480. 5. Data model questions Cardinality. We are inclined to carry an array, since results from more than one issuer or scheme on the same object is a natural case and moving from object to array later would be a breaking change. If we do, the member should be renamed in the same revision rather than a later one, since renaming a protocol element is itself a breaking change. Is that the right call? Non-numeric results. Some programs produce categorical outcomes. We do not intend to let scoreValue be either a number or a string, since changing a member's type is a breaking change and it complicates clients. Distinct members, or a typed result object, seem preferable. Is there a pattern the working group prefers? Freshness. We are inclined to add an explicit validUntil, since a consumer unfamiliar with the scheme has no in-band way to know when a result goes stale. Confidence. A question raised at the microphone that we did not answer: how reliable is the result itself. Should the envelope support an optional, scheme-defined representation of confidence or uncertainty where the methodology is capable of producing one, or does that belong wholly to the scheme? Versioning. We take it from Section 5.4 of draft-ietf-regext-rdap-extensions that extension identifiers are opaque and possess no explicit version despite some containing trailing numbers, and that an extension using a versioning method must describe it explicitly. So the question is not whether ours should imitate geofeed1 or rpki1, but whether this document should define a versioning strategy at all, and if so which. Namespacing drew no comment either way. The -01 uses a single prefixed top-level member with unprefixed children, which we believe is permitted by Section 2.5.2 of the same document, and an identifier without underscores. Absent contrary feedback we currently plan to retain this approach. 6. Venue Section 7.1.2 of draft-ietf-regext-rdap-extensions encourages extension authors to seek informal review by sending a request to this list, which is what we are doing. The current REGEXT charter also covers updates and extensions to RDAP, Standards Track or Experimental, so we believe this list is the natural venue for technical review of an RDAP extension, whoever operates the server. Whether there is enough interest to justify adoption is a separate question, and one we accept has not been answered. 7. What would help most The comment that this may be a solution in search of a problem is fair, and we would rather answer it with evidence than with argument. If you operate or plan to operate an assessment program, implement RDAP clients, or would consume this kind of data, we would like to hear from you, whether you are a registry, a registrar, a researcher, a security vendor or an enterprise consumer. A statement that you would not use it, and why, is equally useful. Best regards, Alessandro Bertoldi (Bertoldi Cybersecurity) Simon Pietro Romano (University of Naples Federico II) draft: https://datatracker.ietf.org/doc/draft-bertoldi-regext-rdap-reliability-scoring/
"Empowering your business with cutting-edge cybersecurity solutions, safeguarding your digital assets and ensuring a seamless, secure experience for your customers." BertoldiCybersecurity Alessandro Bertoldi Owner T. +39 0185 799079 M. +39 348 5130136 E-Mail [email protected] www.bertoldicybersecurity.comhttps://bcsec.io
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
