Giter Site home page Giter Site logo

Comments (12)

arnoldblinn avatar arnoldblinn commented on July 19, 2024

from spec.

anderspitman avatar anderspitman commented on July 19, 2024

@arnoldblinn, thank you for the detailed answers! I think my concerns are reduced to 2 questions:

  1. Sounds like I can create a single template for boringproxy, and anyone who hosts their own boringproxy server can use the synchronous flow (assuming async would require OAuth credentials which I can't share)?

  2. Why is there no provision for anonymous synchronous requests, ie without template required or even some "universal" templates for simple actions such as setting a single A Record? It seems like tying everything to templates with specific provider IDs could actually make phishing worse, because when people see the name and/or logo of the provider they assume it's valid. I understand the phishing warnings and that signing requests solves this but in that case why not support fully anonymous requests with phishing warnings? You can't trust anything in the request so it seems like you shouldn't be showing them the logo or provider ID anyway, at which point why is a template necessary?

from spec.

arnoldblinn avatar arnoldblinn commented on July 19, 2024

from spec.

pawel-kow avatar pawel-kow commented on July 19, 2024

Worth considering, although not perfect, is the approach we took with DynDNS client.
So it's in fact async flow, with confidential client and known predefined secret.
Public client with PKCE would have been better, but this was easier to do at a time as no upgrades needed to the auth servers.

More details:
https://github.com/Domain-Connect/DomainConnectDDNS-Windows

There is also a Python client
https://github.com/Domain-Connect/DomainConnectDDNS-Python

In fact if only A/AAAA records are needed one could piggyback on the same template... it's just OAuth in the end of the day.

from spec.

arnoldblinn avatar arnoldblinn commented on July 19, 2024

from spec.

anderspitman avatar anderspitman commented on July 19, 2024

@arnoldblinn thanks again. I guess I just don't see the difference between showing a phishing warning with a pre-defined template, and showing a phishing warning with a template you pass in the query itself (anonymously). You can't trust the request in either case. And I would argue that showing the service provider name and/or logo in this case is actually worse for security.

Requiring that all templates be predefined and onboarded seems like it would slow adoption and make it much more difficult for small players and open source projects to get involved. I would try implementing Domain Connect today but knowing that I have to get at least one DNS provider to onboard my template makes me wonder if it would take weeks of back-and-forth with me trying to debug my template. And there's no guarantee any of them would choose to onboard it at all.

@pawel-kow thanks for the suggestion. I'm not sure I see the advantage. The synchronous flow should be fine for my project. It looks like the phishing warning is required either way since the secret is public. I feel like your suggestion that I piggyback on the DynDNS template further illustrates my point. If it doesn't matter that I impersonate someone else's service, why are predefined templates required in the first place?

I'm not trying to be contrary. There's a good chance I'm just missing something here, and I want to understand.

from spec.

anderspitman avatar anderspitman commented on July 19, 2024

@arnoldblinn I appreciate your participation so far but recognize that you've mostly moved on from this project. I would value your thoughts moving forward, but please don't feel any obligation.

As a followup, I just bought a domain from Godaddy and built a simple Domain Connect URL using the example template1.

It works as intended (kudos on making an elegant API), but this is what I see:

DeepinScreenshot_select-area_20211216161409

It really seems to me that the use of a predefined template is mostly detrimental as implemented here. Even though warnPhishing is set true in the template, I don't see any indication that there's anything for the user to be concerned about here. What's even more concerning, the inclusion of "Stateless Hosting Primary" and "Example Domain Connect Service" show that the user could easily be mislead into believing they are using a completely different service than indicated.

To be clear, I'm not saying that service provider registration is a bad idea. But I'm advocating two things:

  1. Service provider registration should be optional. Anonymous requests with inline templates should be possible, but clearly marked as untrustworthy.
  2. Any flow that displays information from a template to a user must be signed.

Thoughts?

Also @arnoldblinn, it appears that host=* does not work, for Godaddy at least.

from spec.

arnoldblinn avatar arnoldblinn commented on July 19, 2024

from spec.

pawel-kow avatar pawel-kow commented on July 19, 2024

@anderspitman public template repositiry and the review process in there is happening to save the work for the community.
One important factor for the review is in fact to minimize attack surface for phishing, especially by minimizing possibilities of unintended use of a template or applying additional measures (require signing, warnPhishing, minimize variable parts etc.).
We are not yet that far to have a fully automated rule-set that would allow for such verification on the fly and automated.

The template is in the end of the day an API contract between DNS provider and Service provider (in some cases backed by a read legal agreement). Each time it's a distinct decision of a DNS provider whether to onboard the template and whether to trust the community review process. I can tell most of DNS providers have also own review process before onboarding and most are also onboarding templates out-of-band, for internal usage or for confidential partners.

What we never wanted Domain Connect to be was a generic CRUD-like API for any DNS record, which would eventually keep the doors wide open for any kind of misuse. Domain Connect keeps the scope of user consent as narrow as possible to minimize the risk. And I think it's working very fine for the use-cases it was designed for.

The use-case of standalone tools is a bit difficult as many of the security measures don't work, but as dyndns case shows it's possible and can be very successful.
So I think you can still give it a try with a template for your service. If sync flow works out for you then you should have even easier way to get it rolling.

from spec.

anderspitman avatar anderspitman commented on July 19, 2024

Thanks again both of you.

I will consider implementing Domain Connect for my projects and trying to get DNS providers to accept my templates.

But ultimately I don't think Domain Connect in its current form is really a good fit for self-hosted software. Requiring every open source project to onboard a template with every DNS provider they want to support is simply too much friction. I really think there needs to be support for anonymous requests. Obviously not all DNS providers would have to support them, but I think it should be an option.

Who should I talk to about trying to get this added to Domain Connect? I need this functionality for my projects, but I don't think it makes sense for me to make a completely separate spec that would work basically the same way on a technical level, only with more open/loosely coupled integration policies.

from spec.

pawel-kow avatar pawel-kow commented on July 19, 2024

@anderspitman as mentioned, there are DNS providers that accept templates from the public repo without any review (let' name them group 1). There are ones who do an internal review and accept (group 2) and finally ones which only accept with additional legal agreement (group 3).
I would assume that groups 2&3 won't accept such "template with request" anyways, same as they don't accept templates out of the repository as-is.

No matter if self-hosted or not, the process of making the template public increases the trust and security for the whole community. For the group 1 it actually is functionally equal to passing a template with the request and even opens the door to the group 2 of providers who would accept your template after review. For group 3 you also get a chance, maybe with a little bit more effort and communication, but eventually as examples of DynDNS, ID4me or Plesk (also self-hosted!) show, this is doable and in many cases very successful.

The bottom line - with template approach you can likely reach all 3 groups. With full dynamic - you likely reach only the group 1.

BUT... this is an open community and healthy community lives from active participants, exchange of ideas and open discussions. You are welcome to join the Slack channel and see whether you gain interest from your proposal. I would argue such extension to be a separate specification (similar like "dynamic registration" specifications to OAuth2 or OIDC are separate to the core) but then if few parties are interested to spec it and eventually implement, let it be so.

from spec.

anderspitman avatar anderspitman commented on July 19, 2024

Sorry for the delay. Thanks for the explanation. I still think things are too tightly coupled and the friction is too high for small projects to integrate, but I understand the design decisions based on the problems you're trying to solve. Thanks @arnoldblinn and @pawel-kow!

Hope you have a happy new year!

from spec.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.