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 <[email protected]> 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 -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
