[DNSOP] Re: [Ext] Persistence of DCV, including for Delegated DCV (for draft-ietf-dnsop-domain-verification-techniques)

[Ben Schwartz <[e-mail]>]

Paul W wrote:

> I don't think there was that much disagreement between authors. It was
> mostly a disagreement between authors and Ben Schwartz about whether
> the initial DCV record can or should be used as long term permission
> token.

I believe the current draft text in the datatracker agrees with me.  For example, draft-07 Section 4.3 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 token are no guarantee that the original owner is still in control of the domain, and a new challenge needs to be issued.

Surely something cannot be a "best current practice" if it is also "discouraged" and one "needs" to use the other approach.  However, other portions of the draft are somewhat in tension with this paragraph, hence my PR to try to clarify the draft's stance.

> Talking about life cycles is useful, but I think like the lifecycle for
> SSL certificates, can only be feasibly done if there is an automated
> system like ACME to fully automate this. The question then though, is
> how much real "admin permission" does such a record give you if the
> admin really doesn't know because a certbot like script is running
> someplace authorizing on their behalf?

The (unstated!) presumption of DCV is that an actor who can write a DCV record at _$foo-challenge.$domain can also overwrite any record on $domain.  This actor could already do a lot of bad things, like taking websites on $domain offline, so their permission is sufficient to perform certain actions that pose risk (e.g. creating a risk of DoS), as that risk is not incremental.

Without this assumption (or an equivalent rule about parties authorized to update parts of the zone), DCV doesn't work at all.  Perhaps we need to make that more explicit...

> I still believe we are picking the best of _current_ practices ...

Drawing a very hard distinction between DCV and persistent authorization is certainly a current practice, and in my view (and the view of draft-07!) it is the best one.  Not all current practices are best ... even if they are indeed widely used without incident.

--Ben

________________________________
From: Erik Nygren <[e-mail]>
Sent: Monday, May 12, 2025 12:52 PM
To: Paul Wouters <[e-mail]>
Cc: Paul Hoffman <[e-mail]>; dnsop WG <[e-mail]>
Subject: [DNSOP] Re: [Ext] Persistence of DCV, including for Delegated DCV (for draft-ietf-dnsop-domain-verification-techniques)

I agree with Paul W here. I don't think there's disagreement between the authors, and I believe that it is important to cover\ the current practices where assumptions about persistence are being made. If we go back to the examples that

I agree with Paul W here.  I don't think there's disagreement between the authors, and I believe that
it is important to cover\ the current practices where assumptions about persistence are being made.
If we go back to the examples that were in an appendix of earlier versions of this draft some of them
do assume persistence, and that is part of how we got into this.  As such, I do think we have experience
there with some of the pitfalls of certain implementations around persistence.
(For that matter, an NS record is a form of persistent delegation, although outside the scope of this draft.)

Since this doesn't appear to be clear to some readers it does seem like it would be worthwhile
to add some text to explain point-in-time-validation vs persistent validation and to highlight pitfalls.
I don't really think there is as clear of a distinction between point-in-time validation,
persistent validation, and delegation for ongoing point-in-time validations as Ben implies.
They are all cases which apply and are variations and it would be good to cover all of them
in the draft as the current version does.

      Erik




On Mon, May 12, 2025 at 12:41 PM Paul Wouters <[e-mail]<mailto:[e-mail]>> wrote:
On Mon, 12 May 2025, Paul Hoffman wrote:

[ speaking only as co-author of draft-ietf-dnsop-domain-verification-techniques ]

> Reading this thread and the GitHub issue that spawned it, it is clear that even the co-authors of draft-ietf-dnsop-domain-verification-techniques do not agree on how to handle persistence of validation, much less agreement among WG participants. This may be due to lack of real-world experience with persistent validation, even though we have plenty of experience with single shared secret validation for one instant.

I don't think there was that much disagreement between authors. It was
mostly a disagreement between authors and Ben Schwartz about whether
the initial DCV record can or should be used as long term permission
token.

Ben argues the draft is a BCP and should specify the "best way forward"
and use two different records. My counter argument is that the draft
is a "best CURRENT practice", anod no one I know is currently doing
this.

For reference, the github thread is here: https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/160


> draft-sheth-identifiers-dns is a good start at thinking about the differences between persistent validation and single shared secret validation. It seems safe to limit draft-ietf-dnsop-domain-verification-techniques to just the latter, and hopefully the WG adopts draft-sheth-identifiers-dns and has more discussion about what might become best practices there.

Talking about life cycles is useful, but I think like the lifecycle for
SSL certificates, can only be feasibly done if there is an automated
system like ACME to fully automate this. The question then though, is
how much real "admin permission" does such a record give you if the
admin really doesn't know because a certbot like script is running
someplace authorizing on their behalf?

> I'm posting here because just last week I thought that draft-sheth-identifiers-dns should be part of draft-ietf-dnsop-domain-verification-techniques because there was general agreement on what were best practices. I was wrong, and the more that I thought about what I would say were best practices for persistence validation, the more I realize that I hadn't thought enough about the operational and security considerations.
>
> Given that, I propose that draft-ietf-dnsop-domain-verification-techniques be narrowed to only cover the best current practices for shared secret validation, and get that published sooner rather than later. I further propose that draft-sheth-identifiers-dns be adopted by the WG, on the assumption that it starts with the same naming scheme from draft-ietf-dnsop-domain-verification-techniques.

I still believe we are picking the best of _current_ practices, and I
still believe the document should document that if you are using the
DCV record for continue permission, that it should be clear in the
RDATA using key=value pairs with for example expire=never and that
DCVs that can be removed after a one time verification, SHOULD contain
a expire=<datestamp> value. Punting this discussion further into the
future means there will be more DNS littering until that unknown future
time.

Paul W

_______________________________________________
DNSOP mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>