3 ms·

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 lo

by 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.

by secalex 14y ago

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.