[DNSOP] Re: Request Feedback: draft-sheth-dns-integration

[Ben Schwartz <[e-mail]>]

Section 5.7 of  draft-ietf-dnsop-domain-verification-techniques-05 says


   Some Application Service Providers currently require the Validation
   Record to remain in the zone indefinitely for periodic revalidation
   purposes.  This practice should be discouraged.  Subsequent
   validation actions using an already disclosed secret are no guarantee
   that the original owner is still in control of the domain, and a new
   challenge needs to be issued.

However, this draft implicitly takes the opposite view, as the authors refer to systems that require their validation records to be published as long as the corresponding association exists.

I think the discrepancy is very interesting.  We need to distinguish "this domain is authorized by account $X" and "this domain authorizes account $X".  When performed in the DNS, the former requires a secret and applies to a point in time; the latter requires no secrets and applies continuously.

In general, I think the latter is probably simpler, easier to manage, and more secure.  Perhaps the DCV draft ought to note this.

--Ben
________________________________
From: Sheth, Swapneel <ssheth=[e-mail]>
Sent: Monday, August 5, 2024 12:04 PM
To: [e-mail] <[e-mail]>
Cc: Kaizer, Andrew <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: [DNSOP] Request Feedback: draft-sheth-dns-integration

DNSOP, Just before IETF 120 we published a draft "Integration of DNS Domain Names into Application Environments: Motivations and Considerations" along with co-authors from Bluesky and Ethereum Name Service. You may have seen us socializing


DNSOP,

Just before IETF 120 we published a draft "Integration of DNS Domain Names into Application Environments: Motivations and Considerations<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-sheth-dns-integration/__;!!Bt8RZUm9aw!5uGRf-jrspw4aqbJsmf_WDfAqdK4pnUYUTc4DrvcJhusAcikKdSv1rECFE6DI2WxQj0-qPJM2pr-FgfOlgmBmEB6a2w$>" along with co-authors from Bluesky and Ethereum Name Service.  You may have seen us socializing it at the hackathon and HotRFC<https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/120/materials/slides-120-hotrfc-sessa-03-integration-of-dns-domain-names-into-application-environments-motivations-and-considerations__;!!Bt8RZUm9aw!5uGRf-jrspw4aqbJsmf_WDfAqdK4pnUYUTc4DrvcJhusAcikKdSv1rECFE6DI2WxQj0-qPJM2pr-FgfOlgmB72MD_wo$> or heard the request for feedback during Thursday's DNSOP session when the chairs mentioned it during the "Drafts of Note" of section.

During IETF 120 we received a lot of good feedback around this draft and would like further feedback!  Since the initial 00 version, we have changed the draft to informational and are in the process of evaluating how best to incorporate the other feedback we received.

The goal of this draft is to provide informational guidance to communities who are trying to incorporate DNS domain names into their applications.  The draft currently provides motivations for why applications opt to utilize domain names and qualities that applications should consider as they build and maintain their integrations, e.g., having processes in place to account for domain name lifecycle events or DNS protocol evolution.  We would appreciate feedback on the current draft and other motivations/qualities we should consider including that would make this draft as useful as possible to these communities.

We would be happy to take feedback here on the mailing list.

Thanks,
Swapneel Sheth