Re: [DNSOP] Domain Verification Techniques using DNS

[Shivan Kaul Sahib <[e-mail]>]

Hi Elliott,

On Wed, 24 May 2023 at 14:52, <[e-mail]> wrote:

> ------- Original Message -------
> On Tuesday, May 23rd, 2023 at 21:22, Paul Wouters <paul.wouters=
> [e-mail]> wrote:
>
>
> 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.
>
>
> The current draft's methods (Service Provider: instructing a domain owner
> to create a DNS TXT record; Domain Owner: creating the DNS TXT record) are
> automated on the service provider side, but in my experience it is very
> rarely automated on the domain owner side.
>
> On the domain owner side, there is a human operator following the
> instructions and creating the DNS TXT record.
>
> Our method does involve an extra step of verification (e.g. verifying an
> email address), but in practice this extra step has often already been
> completed when the domain owner set up a user account with the service
> provider.
>
> 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.
>
>
> I am very open to submitting it as a separate draft and I am interested in
> the thoughts of the WG around whether the abstract of the current draft
> (and possibly title) should be narrowed to make it clear the domain
> verification techniques included in the current draft are for one-time only
> / service provider specific domain verification.
>


I agree with Paul that this seems like a separate draft that should be
considered on its own by the WG.


>
> 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.
>
>
> The zonemaster is not the domain owner in the vast majority of cases. I
> think there's a variety of reasons this email address is no longer used by
> anyone, including: it is in plaintext so easily discoverable; there are
> better ways to contact the administrator of a DNS zone.
>
> Hashing the contact info is only a very wea protection, as we have seen
> with people bruteforcing NSEC3 hash chains.
>
>
> We hash the email/phone and store it in the DNS label itself so that it
> cannot be easily harvested by spammers. We don't use hashing for any kind
> of protection against a threat.
>
> And also, I think
> these type of records will also go stale and then not very useful.
>
>
> These records will naturally be removed when a domain expires or changes
> registrant, so I think the risk of stale records for a domain owner is
> quite low. Records for third parties can have expiry dates, so I think this
> should avoid stale records for third parties.
>
> 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.
>
>
> I would argue that the service providers that verify the most domains
> already verify email addresses on sign-up. And so, once the Domain
> Verification Protocol record is in place – whether it's been setup by the
> domain registrant, registrar or a previous service provider – domain
> verification becomes "automatic" and significantly easier than "take this
> DNS record and tell your IT to publish it for a few days".
>
> I have provided an explanation of the process below:
>
> 1. Bob signs up with DomainRegistrar.com using email [e-mail] and
> registers the available domain example.com
>
> 2. DomainRegistrar.com configures a Domain Verification record by hashing
> [e-mail] (simplified hash: 123ABC) and stores this record at 123ABC._
> dv.example.com
>
> 3. Bob signs up with Service Provider 1 using his email [e-mail] and
> verifies his email. He attempts to add the domain example.com to the
> service provider
>
> 4. Service Provider 1 runs a Domain Verification check for the domain
> example.com by hashing Bob’s email ([e-mail] -> 123ABC) and using
> this in a dns query:
> dig 123ABC._dv.example.com
>
> 5. If a valid record is returned then Domain Verification is successful.
>
> 6. Bob can claim example.com on multiple service providers using the same
> steps above, without adding any DNS TXT records.
>
> In the example above, the Registrar creates the record but this record
> could also be created by Bob himself under instruction from the first
> Service Provider he uses. Subsequent Service Providers could re-use the
> same record.
>
>
> 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.
>
>
> Thanks and noted.
>
> - 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.
>
>
> I am new to this so my apologies if I've misinterpreted something, but In
> RFC8179 I noted the following, particularly (b):
>
> *"Since IPR disclosures will be used by IETF working groups during their
> evaluation of alternative technical solutions, it is helpful if an IPR
> disclosure includes information about licensing of the IPR in case
> Implementing Technologies require a license. Specifically, it is helpful to
> indicate whether, upon approval by the IESG for publication as an RFC of
> the relevant IETF specification(s), all persons will be able to obtain the
> right to implement, use, distribute, and exercise other rights with respect
> to an Implementing Technology a) under a royalty-free and otherwise
> reasonable and non-discriminatory license, or b) under a license that
> contains reasonable and non-discriminatory terms and conditions, including
> a reasonable royalty or other payment, or c) without the need to obtain a
> license from the IPR holder (e.g., a covenant not to sue with or without
> defensive suspension, as described in Section 7)."*
>
> As per (b), our technology will be offered "under a license that contains
> reasonable and non-discriminatory terms and conditions, including a
> reasonable royalty or other payment".
>
> I understand the IETF might lean towards non-proprietary technology or
> proprietary technology that is freely-licensed.
>
> I suppose my question, and the reason for contacting the IETF boils down
> to whether or not the draft (with it's current title and abstract) is
> aiming to be complete in it's consideration of "Domain Verification
> Techniques using DNS". If so, I would argue our method should be considered
> for inclusion.
>

I disagree, the draft has been adopted as a Best Current Practice document
(see the intended status in the boilerplate). The abstract currently says:

   Many services on the Internet need to verify ownership or control of
   a domain in the Domain Name System (DNS).  This verification is often
   done by requesting a specific DNS record to be visible in the domain.
   There are a variety of techniques in use today, with different pros
   and cons.  This document proposes some practices to avoid known
   problems.

The draft surveyed several widely deployed techniques and synthesized best
current practices. The technique you're proposing is a new technique, and
worth considering in its own separate document by the DNSOP working group.

>
> If instead it is intended to standardise the method widely used over the
> last 10-15 years then I wonder whether the draft and abstract should be
> narrowed to make that clear.
>

I think the Intended Status and Abstract together make this clear.


> 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
> :)
>
>
> Thank for the time and consideration you've given to this.
>
>
> Paul
>
>
> Best regards,
>
> Elliott
>


Thanks,
Shivan