Re: [DNSOP] Domain Verification Techniques using DNS

[Paul Wouters <[e-mail]>]

On Mon, May 22, 2023 at 5:49 PM <[e-mail]> wrote:

> Dear DNSOP WG,
>
> My company has developed a domain verification technique using DNS, it
> fits the abstract of draft-ietf-dnsop-domain-verification-techniques.
>
> I am writing to ask the WG's opinion on whether our technique is within
> the scope of the current draft and if so, whether it should be considered
> for inclusion.
>

Thanks for reaching out to DNSOP.


>
> Our technique is outlined here:
> https://www.domainverification.org
>
> You can see an example DNS TXT record by using the following dig command:
>
> dig 4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg._dv.dvexample.com
> TXT
>
> Although our method fits the draft's title and abstract, it is quite
> different to the method detailed in the best current practice of the draft.
>

Indeed. While the current draft's methods could be fully automated, your
method specifically calls out for verification via
a phone number or email address which more or less assumes a human
operator. It therefor works indirectly and all the
"verification" parts are out of scope handled inside the SMS / email /
phone call messages that would be required.

As such, I do not think it belings in the current draft, but should be
submitted as a separate draft.


It is our ultimate goal for these records to be created by domain
> registrars upon domain registration (with registrant opt-in) to provide
> their customers with seamless onboarding when adding their domain to
> service providers.
>

I wonder if that goal is achievable. In a way, the SOA record also contains
a contact email for the domain and is basically no longer used by anyone.
Hashing the contact info is only a very wea protection, as we have seen
with people bruteforcing NSEC3 hash chains. And also, I think
these type of records will also go stale and then not very useful. And so
another fallback mechanism will be required anyway. So perhaps using that
fallback to start with would be better.  (I guess you could add some
application code to verify email addresses on signup requests, but I doubt
this is all going to me that much easier than "take this DNS record and
tell your IT to publish it for a few days" that the current draft uses.


> In accordance with BCP79, I am disclosing the following patents which
> relate to our technology:
>
> Patents related to storing a hash of a verifiable identifier (email,
> phone, etc) in DNS for the purposes of verification:
>
> - UK granted patent: https://patents.google.com/patent/GB2585353B


I believe that  RFC 7929 - DNS-Based Authentication of Named Entities, of
which I am the author, constitutes prior art for this patent.


> - US pending patent: https://patents.google.com/patent/US20220141172A1
>
> Patents related to storing a hash of a verifiable identifier as a DNS
> label for the purposes of verification:
>
> - UK pending and unpublished patent:
> https://patents.google.com/patent/GB202216304D0


I believe both the aforementioned RFC 7929, as well as RFC 7671: The
DNS-Based Authentication of Named Entities,
constitute prior art for this patent.


> - US patent to be filed.
>
> As I understand it, this disclosure is a condition of contributing to the
> discussion. For the avoidance of doubt: I am not asserting any rights over
> the methods discussed in the current draft at all – only our new method
> being proposed for inclusion.
>
> We are still working on licensing but creating Domain Verification records
> will always be free for domain registrants or registrars, service providers
> will require a license to verify domains using the protocol.
>

Note that the IETF strongly leans towards only using patented technology if
that technology is licensed using an irrevocable, perpetual, royalty free
and non-discriminatory license. Your indication that service providers
cannot use this technology without paying royalties would not be compatible
with that goal.


> This is my first time contributing to the IETF, please forgive me for any
> accidental transgressions – I am here to contribute as productively as
> possible.
>

Welcome and thanks for coming to the IETF to make the internet work better
:)

Paul