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
<shivankaulsa...@gmail.com> wrote:
> Hi Elliott,
>
> On Wed, 24 May 2023 at 14:52, <elliott.br...@num.uk> wrote:
>
>> ------- Original Message -------
>> On Tuesday, May 23rd, 2023 at 21:22, Paul Wouters
>> <paul.wouters=40aiven...@dmarc.ietf.org> wrote:
>>
>>> On Mon, May 22, 2023 at 5:49 PM <elliott.br...@num.uk> 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 emailbob@gmail.comand
>> registers the available domain[example.com](http://example.com/)
>>
>> 2. DomainRegistrar.com configures a Domain Verification record by
>> hashing...@gmail.com(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 emailbob@gmail.comand
>> 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
>> (b...@gmail.com-> 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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
