Re: [DNSOP] Domain Verification Techniques using DNS

[[e-mail]]

Thank you for your reply Shivan,

Your comment cleared some things up for me:

> 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.

It's now clear that our technique is not widely deployed and so I understand that it might not be relevant for a Best Current Practice document. I think this could be a lack of understanding on my part about how BCP documents work and so I'll do some reading on that.

Thanks for your help,

Elliott

------- Original Message -------
On Wednesday, May 24th, 2023 at 23:03, Shivan Kaul Sahib <[e-mail]> wrote:

> 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 [e-mail] registers the available domain[example.com](http://example.com/)
>>
>> 2. DomainRegistrar.com configures a Domain Verification record by [e-mail](simplified hash: 123ABC) and stores this record at 123ABC._[dv.example.com](http://dv.example.com/)
>>
>> 3. Bob signs up with Service Provider 1 using his [e-mail] verifies his email. He attempts to add the domain[example.com](http://example.com/)to the service provider
>>
>> 4. Service Provider 1 runs a Domain Verification check for the domain[example.com](http://example.com/)by hashing Bob’s email ([e-mail]-> 123ABC) and using this in a dns query:
>> dig 123ABC._[dv.example.com](http://dv.example.com/)
>>
>> 5. If a valid record is returned then Domain Verification is successful.
>>
>> 6. Bob can claim[example.com](http://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