Question/Feature Request: DNSSEC usage for 1password hosted endpoints
Hi!
I lately looked more and more into securing DNS for myself, which also included monitoring the requests for any missing DS records on the DNS server. Who has thought, there are a lot of missing ones! :| So moving to strict mode won't be an option in the near future. But making one by one secure is already a start.
So my question or maybe also more likely feature request is, did you already look into securing your public facing services with DNSSEC?
As far as I can see 1password.com does not have any DS records up to now ( https://dnssec-analyzer.verisignlabs.com/1password.com )
(this is only a example off course you have a lot of other endpoints)
This whole topic is mostly about making sure nobody can spoof the DNS records for you, so it might be a plus point for the security of your service :chuffed:
Thanks for hearing me out!
~lumarel
PS: I opened that here in the Windows side, as I'm mostly residing here, but if there is a better place, feel free to move this thread :)
1Password Version: latest Windows/macOS/Linux Beta
Extension Version: Both latest extenstions
OS Version: Not Provided
Sync Type: my.1password.com
Comments
-
Great question @lumarel.
Short answer
Yes, we have looked at DNSSEC on a number of occasions, but each time we looked at it we felt that the security gain wasn't worth the trouble at the time. But we also felt that we would return to the question again every now and then to review how things may have changed since we last looked at it.
Not to short answer
It's more work than it might first appear
One thing that makes it complicated for us to use DNSSEC is that our DNS set-up a bit trickier than most with respect to subdomains. For many types of 1Password accounts have subdomains of
YOUR-NAME-HERE.1password.com, but we do not create DNS records for each of those subdomains. While it would be possible to get our mechanism of subdomain resolution to work with DNSSEC it would involve more moving parts that would interact with the load balancers, DNS servers, and resolvers we already have.Ultimately things like this (consider key pinning as well) can provide more mechanisms that can break and make 1Password inaccessible. And so we need to balance that agains the security gain of using such a mechanism.
It's less of a gain than it might first appear
The good news is that the security gain from DNSSEC is smaller than it used to be or for other types of services. The main security gain is that the client can have (more) trust that it is speaking to the correct server. In the case of 1Password, we built mutual authentication into 1Password's authentication itself. When your client logs into 1Password, you do not just prove yourself to the server, but the server proves itself to you. The sort of mathematical puzzles that the client and server through at each either each prove to the other that they have an account specific secret. In particularly we are using a PAKE (Password-based Authenticated Key Exchange) system known as SRP (Secure Remove Password). Depending on the level of detail you would like to go into to understand how that mathematic magic works, take a look at our support article on SRP, a blog post (or two) about SRP, or even our open source Golang implementation of SRP.
The operation of TLS around the world has also improved greatly since DNSSEC was first proposed. As more sites and services are HTTPS-only and browsers more visibly report HTTP (without the S) as insecure, the need for DNSSEC has diminished.
This is not to say that there wouldn't be some protections that DNSSEC might offer, particularly when using the web-client instead of a downloaded locally installed client. And so we do consider those each and every time we take another look at DNSSEC. So far, as you have seen, we have chosen that the risks and complexity of DNSSEC for 1Password are not worth the potential security gains. Over the years, the potential security gains have diminished, and we expect that to continue, so I'm not anticipating much of a change in policy the next time we review the issue, but we will see what things are like then.
0 -
Thank you for taking the time @jpgoldberg !
(sorry that it took me that long too answer, had a quite busy time)
Off course DNSSEC is nothing which can be enabled with one switch, and I definitely don't know how the 1Password backend works in detail, so it was more like a humble request up to now :)
It's good to hear that you thought about implementing and the cost of implementing DNSSEC! (I just did not see any conversions about this topic here up to now) Even as you said it just does not have enough benefits against the higher risk of getting an unstable system.As I made my switch to the subsubscription based model including using 1Passwords storage system, I took a lot of time to read and understand the security whitepaper, so I might have already read some parts of the process including SRP. But thank you for making it even more clear how this key exchange system works!
So this definitely shrinks the need of a prove like with DNSSEC, maybe it is possible to get any information like the initial packet which gets sent by the client to the server to build up the connection, but from my understanding this is not enough information to get to anywhere :+1:About the diminishing need of DNSSEC due to the HTTPS-only services including the better visibility in browsers.. I would say yes but also no, it definitely improved a lot of the security concerns of the past, but it also happened a few times that CAs gave out certificates, even if they weren't allowed to, how they even managed to do that ^^ DNSSEC proves that the provided record also targets to the correct IP address and did not get spoofed.
In my case I rarely use the web-client so good to know that the desktop/cli-client is more secure than the web-client.
Anyway, I see that you and your team are taking a lot of effort to stay up to date with your security policies for the backend services!
One more time, thank you for taking the time for explaning how the decision was made :chuffed: (and sorry for my maybe partly broken English)0 -
@lumarel is absolutely correct that,
it also happened a few times that CAs gave out certificates, even if they weren't allowed to, how they even managed to do that ^^ DNSSEC proves that the provided record also targets to the correct IP address and did not get spoofed.
Agreed. DNSSEC isn't entirely redundant. It does provide meaningful defense in depth around certain sorts of attacks. As with anything, it is question of given its diminished (but not eliminated) value whether it is worth it, including worth the risk of an error in certificate management leading to lockout.
It's not that we don't know how to manage certificates, but for DNSSEC to add the value you describe we would definitely want to use a different CA. This means that we double the chances that something up our certificate chain is revoked or becomes untrustworthy. (Consider Diginotar). An event like that would kill off availability until we were able to get a certificate in place. This is always a risk, and one very much worth taking for the benefits of TLS and the like. But do we want to double the risk for a relatively small gain?
Some people would say, "yes". We've said, "no." It is certainly the kind of thing that people can reasonably disagree about.
The real goal is to improve the security of the delivery of the web-client or reduce dependency on it. Both are things that we have been doing, but they are through smaller, incremental, measures.
0
