6 ms·

This sounds great, but it's not really a solution to the hard problems with crypto. The single biggest impetus to a fully encrypted internet is not a technical

This sounds great, but it's not really a solution to the hard problems with crypto. The single biggest impetus to a fully encrypted internet is not a technical barrier, but the fact their are too many competing systems and standards, all with different drawbacks, but generally all of which give terrible UX. For an encrypted web to become ubiquitous, there will need to be a set-it-and-forget-it solution that requires minimal input from the user and which doesn't reduce functionality. Using .secure just asks users to instead place their trust in a new central authority; why does this even need to be a new TLD? This researcher is wasting money buying into ICANN's bullshit monopoly. The future of strong crypto systems will most certainly be decentralized.

secalex 14y ago
Howdy, that article is about me, and I do agree that crypto trust systems need to become more decentralized. People seem to be reacting to the story without looking into the technical details, so I'll try to avoid http://xkcd.com/386/ http://xkcd.com/386/, but I will say that one of our goals with Domain Policy Framework (which we will release a draft of tomorrow) is to create the policy and identity that, combined with DNSSEC and DANE, allow for more granular (but not completely decentralized) trust relationships. I think we agree about UX. One of the big picture goals of .secure is to invert the current security experience. These days you go to a site and then have to interpret the UI to see if you are safe. In our vision, when you type bank.secure you are telling your browser, OS and the server on the other side that you want to navigate there as safely as possible. I'm going to post about the tech details more tomorrow and hopefully that clears some things up.
- nextstep 14y ago
  I guess we'll have to wait until you post the technical details, but from the Ars article, it sounds like this page is using existing standards (TLS, maybe some other stuff). That's fine, but what's the incentive for a bank or any secure online service to use this instead of the expected <bank>.com domain name? When I browse to a secure page (https) in my browser, I'm told that the connection is secure with a green https prefix in the address bar. But I don't really know it's secure. I'm placing my trust in the CAs. Using .secure to signal a secure connection to user doesn't improve this. It just complicates things further, because now there's two things a savvy user should look for if he/she expects a secure connection (https and .secure). Because you seem like a fan of XKCD: http://xkcd.com/927/ http://xkcd.com/927/ Creating a new UI standard works best when it kills (totally replaces) it's predecessor. In this case, I think that translates to having every site which currently uses https make the switch to .secure. That seems unlikely to me.
  - secalex 14y ago
    The UX should be the equivalent of the current EV UX, but the point is that if your browser supports DPF then you don't need to look. If you got there after typing bank.secure, you should be good. If the screen is red (and hopefully doesn't have an "accept this risk" button) then you didn't. I should point out this is about more than TLS, and more than the web. We have a short window during which we can create an Internet category that is both clear to the user in it's goals and specific in its requirements for hosts. Our hope is to create an extensible protocol with DPF, one that can be extended to give domain registries and registrants the ability to choose higher privacy protections, limit risk to CA compromise, and secure other protocols like SMTP.

secalex 14y ago

Howdy, that article is about me, and I do agree that crypto trust systems need to become more decentralized. People seem to be reacting to the story without looking into the technical details, so I'll try to avoid http://xkcd.com/386/ http://xkcd.com/386/, but I will say that one of our goals with Domain Policy Framework (which we will release a draft of tomorrow) is to create the policy and identity that, combined with DNSSEC and DANE, allow for more granular (but not completely decentralized) trust relationships. I think we agree about UX. One of the big picture goals of .secure is to invert the current security experience. These days you go to a site and then have to interpret the UI to see if you are safe. In our vision, when you type bank.secure you are telling your browser, OS and the server on the other side that you want to navigate there as safely as possible. I'm going to post about the tech details more tomorrow and hopefully that clears some things up.

nextstep 14y ago
I guess we'll have to wait until you post the technical details, but from the Ars article, it sounds like this page is using existing standards (TLS, maybe some other stuff). That's fine, but what's the incentive for a bank or any secure online service to use this instead of the expected <bank>.com domain name? When I browse to a secure page (https) in my browser, I'm told that the connection is secure with a green https prefix in the address bar. But I don't really know it's secure. I'm placing my trust in the CAs. Using .secure to signal a secure connection to user doesn't improve this. It just complicates things further, because now there's two things a savvy user should look for if he/she expects a secure connection (https and .secure). Because you seem like a fan of XKCD: http://xkcd.com/927/ http://xkcd.com/927/ Creating a new UI standard works best when it kills (totally replaces) it's predecessor. In this case, I think that translates to having every site which currently uses https make the switch to .secure. That seems unlikely to me.
- secalex 14y ago
  The UX should be the equivalent of the current EV UX, but the point is that if your browser supports DPF then you don't need to look. If you got there after typing bank.secure, you should be good. If the screen is red (and hopefully doesn't have an "accept this risk" button) then you didn't. I should point out this is about more than TLS, and more than the web. We have a short window during which we can create an Internet category that is both clear to the user in it's goals and specific in its requirements for hosts. Our hope is to create an extensible protocol with DPF, one that can be extended to give domain registries and registrants the ability to choose higher privacy protections, limit risk to CA compromise, and secure other protocols like SMTP.