4 ms·

I’m struggling to understand how this makes any sense given the creators own argument. They say the hardest part is that users don’t know how to adjust their D

I’m struggling to understand how this makes any sense given the creators own argument. They say the hardest part is that users don’t know how to adjust their DNS, and then the solution proposed is adding a DNS record? There are already standards (IETF RFC) why is this better than those?

elliottinvent 3y ago
1. One record can be used by all service providers (set and forget) 2. Records could be created automatically upon domain registration (with opt-in) The current IETF standards don't enable either of the above.
- linuxdude314 3y ago
  That would imply if someone signs up for a service I am not using (with my verified domain), I am going to receive an email or other sort of verification request. That seems like a reduced security posture to me (maybe worthwhile to some). What you are proposing provides DNS based authentication, but not necessarily authorization in contrast to current systems. In your system the auth relies on the operator of the email address or phone number. In situations where you have a NOC or other tier 1 team that normally wouldn’t have access to create TXT records this presents a security hole.
  - elliottinvent 3y ago
    > That would imply if someone signs up for a service I am not using (with my verified domain), I am going to receive an email or other sort of verification request. Your domain is verified by each service provider using the protocol, so it's not really possible for a service you're not using to consider the domain verified already. Of course, it is possible for an attacker to try to verify your domain name with a new service provider by entering your email on user signup / domain verification and claiming to be you. This would as you say prompt the service provider to send a verification email, but that's what would happen today anyway if an attacker attempted to sign you up to a new service. > What you are proposing provides DNS based authentication, but not necessarily authorization in contrast to current systems. Could you elaborate here for me? > In your system the auth relies on the operator of the email address or phone number. In the case where a domain already has a Domain Verification record, then that's correct. In the case where a Domain Verification record does not already exist then it relies on someone with access to DNS. > In situations where you have a NOC or other tier 1 team that normally wouldn’t have access to create TXT records this presents a security hole. Sorry, I'm sure I'm being dense but could you provide an example of the sort of security hole you're seeing here.
    - linuxdude314 3y ago
      My use of authorization was a bit vague.. what I meant is that with your scheme, you implicitly assume I want a particular application to be authenticated. This leaves the user vulnerable to someone else launching accounts on providers they don’t use, that point to your verification record. It’s much more secure to add a DNS record for each system (maybe even each instance/user) as you are explicitly authorizing access to that application via your domain.

elliottinvent 3y ago

1. One record can be used by all service providers (set and forget) 2. Records could be created automatically upon domain registration (with opt-in) The current IETF standards don't enable either of the above.

linuxdude314 3y ago
That would imply if someone signs up for a service I am not using (with my verified domain), I am going to receive an email or other sort of verification request. That seems like a reduced security posture to me (maybe worthwhile to some). What you are proposing provides DNS based authentication, but not necessarily authorization in contrast to current systems. In your system the auth relies on the operator of the email address or phone number. In situations where you have a NOC or other tier 1 team that normally wouldn’t have access to create TXT records this presents a security hole.
- elliottinvent 3y ago
  > That would imply if someone signs up for a service I am not using (with my verified domain), I am going to receive an email or other sort of verification request. Your domain is verified by each service provider using the protocol, so it's not really possible for a service you're not using to consider the domain verified already. Of course, it is possible for an attacker to try to verify your domain name with a new service provider by entering your email on user signup / domain verification and claiming to be you. This would as you say prompt the service provider to send a verification email, but that's what would happen today anyway if an attacker attempted to sign you up to a new service. > What you are proposing provides DNS based authentication, but not necessarily authorization in contrast to current systems. Could you elaborate here for me? > In your system the auth relies on the operator of the email address or phone number. In the case where a domain already has a Domain Verification record, then that's correct. In the case where a Domain Verification record does not already exist then it relies on someone with access to DNS. > In situations where you have a NOC or other tier 1 team that normally wouldn’t have access to create TXT records this presents a security hole. Sorry, I'm sure I'm being dense but could you provide an example of the sort of security hole you're seeing here.
  - linuxdude314 3y ago
    My use of authorization was a bit vague.. what I meant is that with your scheme, you implicitly assume I want a particular application to be authenticated. This leaves the user vulnerable to someone else launching accounts on providers they don’t use, that point to your verification record. It’s much more secure to add a DNS record for each system (maybe even each instance/user) as you are explicitly authorizing access to that application via your domain.