4 ms·

What would the solution be?

by jonny_eh 12y ago

wyager 12y ago
A distributed secure key-value system a la Namecoin.
- uwutnope 12y ago
  You have to store the blockchain on your computer to be able to browse website securely via namecoin, if you use 'light wallets' you will end up with the same DNS as today (trust a third party DNS server + CA or Namecoin node). You could use http://convergence.io/ http://convergence.io/ type of idea to connect to two trusted Namecoin nodes but do we really expect the average user to keep a list of trusted nodes?
  - wyager 12y ago
    You can have trustless namecoin without storing the blockchain, using techniques like SPV.
    - uwutnope 12y ago
      According to https://en.bitcoin.it/wiki/Thin_Client_Security https://en.bitcoin.it/wiki/Thin_Client_Security SPV relies on the trust of your ISP. When nodes send you the blockchain data, is that an encrypted transfer or open to MITM?
  - ryan-c 12y ago
    If you only want to be able to resolve against Namecoin, it's possible to build a client that stores only the unspent transaction output set for names and a few dozen recent blocks and full security.
    - uwutnope 12y ago
      How does that scale in filesize if Namecoin had 215 million~ domain names like we have in the current ICANN system? Also, what would the solution be for smartphones, downloading even just a few blocks isn't preferable with phone networks.
richardwhiuk 12y ago
DANE TLSA is probably the best current option.
- AlyssaRowan 12y ago
  On that note, it's worth taking a look at https://tools.ietf.org/html/draft-nygren-service-bindings-00 https://tools.ietf.org/html/draft-nygren-service-bindings-00 - the "B" record, which is in a very early speculative draft. One shot among several at gluing this stuff together.
exo762 12y ago
Convergence by Moxie Marlinspike. Some argue that it does worse then CA in protecting against low-profile phishing attacks, but that's just bollocks.
rakoo 12y ago
dnschain: https://github.com/okTurtles/dnschain https://github.com/okTurtles/dnschain
- ryan-c 12y ago
  okTurtles is one of several middleware options that runs on top of Namecoin, implementing the domain record spec. It advocates using someone else's trusted server as a data source, but does not at this time implement any integrity protection for data in transit. http://www.freespeechme.org/ http://www.freespeechme.org/ is a more mature and more secure.
  - rakoo 12y ago
    > It advocates using someone else's trusted server as a data source Wrong; it advocates using your own server, but proposes public servers for tests. Here's an excerpt of the README: DNSChain is meant to be run by individuals! Yes, you can use a public DNSChain server, but it's far better to use your own because it gives you more privacy, makes you more resistant to censorship, and provides you with a stronger guarantee that the responses you get haven't been tampered with by a malicious server.
    - ryan-c 12y ago
      I must have either misremembered or it has been changed since I last looked, then. It is still the case that using DNSChain will not get you validated SSL for .bit domains without additional software. It can serve DANE records, but the browser won't verify them and the existing browser extensions for adding DANE support require DNSSEC which DNSChain does not provide.
      - itistoday2 12y ago
        > It is still the case that using DNSChain will not get you validated SSL for .bit domains without additional software. Yes, just like FreeSpeechMe it the SSL validation will initially work via a browser extension, but unlike FSM (heh) it does not carry the additional baggage of requiring you to run a Namecoin node on your [phone/laptop/etc.].
peterwwillis 12y ago
A) Have the initial connection give the client all the domain verification info it needs for the future. Now secure connections can be established with or without a CA. Upside: independence, only one time you can exploit the connection. Downside: anyone can mitm the connection forever from the first connect onwards. B) Use a third party to register the information to secure the initial connection. This is what CAs were created for, and now people are suggesting DNS (and I would wager somebody might recommend whois at some point) as central trusted authorities for this data. Upside: no initial connection mitm, attack surface is minimized compared to number of CAs, distributed model. Downside: still a 3rd-party central authority, and due to smaller attack surface one successful attack could have much wider-ranging consequences, and it adds complication. C) Decentralized network of 3rd party peers to share authority information. Upside: decentralized, loosely organized, requires a bigger attack surface to disable. Downside: peers not held to as high a security standard, not necessarily businesses so no guarantees of integrity. D) Require the user get out-of-bounds information to verify the integrity of initial connection, and after that any connection between the source and destination is secured in any number of ways. Upside: total security not dependent on 3rd parties, no man in the middle. Downside: incredibly inconvenient and totally unscalable. E) All of the above. Support all possible schemes and allow the domain and the users to determine which of them they will use. Layer all different forms of verification so that the number of successful exploits to achieve a fake cert is so complicated that only a few dedicated state actors or elite hackers would spend enough time on it to be successful. Upside: users have choice, domain owners have choice, increased security overall. Downside: browsers have to figure out how to explain to the users what the fuck is going on when they get a warning about a cert now.
- me1010 12y ago
  The problem is that a CA is issuing two things: 1. An identity. 2. A secure communications certificate. These do not need to be the same thing or issued by the same entity. I propose to modify the system as follows: 1. Register a domain name using an email address and a PGP key. 2. The registrar verifies that the applicant has the private key by requiring a clicked link in an encrypted mail. 3. A phone number is required for "full trust". 4. Thus with a private PGP key and a phone, trust that the applicant is the applicant has been established. It really doesn't matter who or what that applicant is -- just that the applicant and only that applicant has the required items. 5. The registrar passes the public key and the top domain to DNS servers. DNS validates against the registrar. And trust in the domain as an entity is now established. 6. Secure communications with the domain can now be established through the use of certs issued by the top level domain. And the domain becomes it's own authority. Any changes to registrar/domain information requires decrypting an email and answering a phone. Expensive and compromised CA's go away - Domain records become secure - Trust becomes decentralized - And domain owners hold all the keys... The only thing anyone else has is the domain holder's public key... SSL itself remains in place as is... Sure, if you lose your private key - you're screwed -- but that's just owning up being a responsible domain owner.
Qantourisc 12y ago
DNS Dane, SSL singing with 2 CA's, peer-based trust, SSL pinning. We probably need a mix ... and none seems to be ideal. What would help is be more ruthless when CA's mess up, and no the pussy approach we are using now: do nothing.

What would the solution be?

wyager 12y ago

A distributed secure key-value system a la Namecoin.

uwutnope 12y ago
You have to store the blockchain on your computer to be able to browse website securely via namecoin, if you use 'light wallets' you will end up with the same DNS as today (trust a third party DNS server + CA or Namecoin node). You could use http://convergence.io/ http://convergence.io/ type of idea to connect to two trusted Namecoin nodes but do we really expect the average user to keep a list of trusted nodes?
- wyager 12y ago
  You can have trustless namecoin without storing the blockchain, using techniques like SPV.
  - uwutnope 12y ago
    According to https://en.bitcoin.it/wiki/Thin_Client_Security https://en.bitcoin.it/wiki/Thin_Client_Security SPV relies on the trust of your ISP. When nodes send you the blockchain data, is that an encrypted transfer or open to MITM?
- ryan-c 12y ago
  If you only want to be able to resolve against Namecoin, it's possible to build a client that stores only the unspent transaction output set for names and a few dozen recent blocks and full security.
  - uwutnope 12y ago
    How does that scale in filesize if Namecoin had 215 million~ domain names like we have in the current ICANN system? Also, what would the solution be for smartphones, downloading even just a few blocks isn't preferable with phone networks.

richardwhiuk 12y ago

DANE TLSA is probably the best current option.

AlyssaRowan 12y ago
On that note, it's worth taking a look at https://tools.ietf.org/html/draft-nygren-service-bindings-00 https://tools.ietf.org/html/draft-nygren-service-bindings-00 - the "B" record, which is in a very early speculative draft. One shot among several at gluing this stuff together.

exo762 12y ago

Convergence by Moxie Marlinspike. Some argue that it does worse then CA in protecting against low-profile phishing attacks, but that's just bollocks.

rakoo 12y ago

dnschain: https://github.com/okTurtles/dnschain https://github.com/okTurtles/dnschain

ryan-c 12y ago
okTurtles is one of several middleware options that runs on top of Namecoin, implementing the domain record spec. It advocates using someone else's trusted server as a data source, but does not at this time implement any integrity protection for data in transit. http://www.freespeechme.org/ http://www.freespeechme.org/ is a more mature and more secure.
- rakoo 12y ago
  > It advocates using someone else's trusted server as a data source Wrong; it advocates using your own server, but proposes public servers for tests. Here's an excerpt of the README: DNSChain is meant to be run by individuals! Yes, you can use a public DNSChain server, but it's far better to use your own because it gives you more privacy, makes you more resistant to censorship, and provides you with a stronger guarantee that the responses you get haven't been tampered with by a malicious server.
  - ryan-c 12y ago
    I must have either misremembered or it has been changed since I last looked, then. It is still the case that using DNSChain will not get you validated SSL for .bit domains without additional software. It can serve DANE records, but the browser won't verify them and the existing browser extensions for adding DANE support require DNSSEC which DNSChain does not provide.
    - itistoday2 12y ago
      > It is still the case that using DNSChain will not get you validated SSL for .bit domains without additional software. Yes, just like FreeSpeechMe it the SSL validation will initially work via a browser extension, but unlike FSM (heh) it does not carry the additional baggage of requiring you to run a Namecoin node on your [phone/laptop/etc.].

peterwwillis 12y ago

A) Have the initial connection give the client all the domain verification info it needs for the future. Now secure connections can be established with or without a CA. Upside: independence, only one time you can exploit the connection. Downside: anyone can mitm the connection forever from the first connect onwards. B) Use a third party to register the information to secure the initial connection. This is what CAs were created for, and now people are suggesting DNS (and I would wager somebody might recommend whois at some point) as central trusted authorities for this data. Upside: no initial connection mitm, attack surface is minimized compared to number of CAs, distributed model. Downside: still a 3rd-party central authority, and due to smaller attack surface one successful attack could have much wider-ranging consequences, and it adds complication. C) Decentralized network of 3rd party peers to share authority information. Upside: decentralized, loosely organized, requires a bigger attack surface to disable. Downside: peers not held to as high a security standard, not necessarily businesses so no guarantees of integrity. D) Require the user get out-of-bounds information to verify the integrity of initial connection, and after that any connection between the source and destination is secured in any number of ways. Upside: total security not dependent on 3rd parties, no man in the middle. Downside: incredibly inconvenient and totally unscalable. E) All of the above. Support all possible schemes and allow the domain and the users to determine which of them they will use. Layer all different forms of verification so that the number of successful exploits to achieve a fake cert is so complicated that only a few dedicated state actors or elite hackers would spend enough time on it to be successful. Upside: users have choice, domain owners have choice, increased security overall. Downside: browsers have to figure out how to explain to the users what the fuck is going on when they get a warning about a cert now.

me1010 12y ago
The problem is that a CA is issuing two things: 1. An identity. 2. A secure communications certificate. These do not need to be the same thing or issued by the same entity. I propose to modify the system as follows: 1. Register a domain name using an email address and a PGP key. 2. The registrar verifies that the applicant has the private key by requiring a clicked link in an encrypted mail. 3. A phone number is required for "full trust". 4. Thus with a private PGP key and a phone, trust that the applicant is the applicant has been established. It really doesn't matter who or what that applicant is -- just that the applicant and only that applicant has the required items. 5. The registrar passes the public key and the top domain to DNS servers. DNS validates against the registrar. And trust in the domain as an entity is now established. 6. Secure communications with the domain can now be established through the use of certs issued by the top level domain. And the domain becomes it's own authority. Any changes to registrar/domain information requires decrypting an email and answering a phone. Expensive and compromised CA's go away - Domain records become secure - Trust becomes decentralized - And domain owners hold all the keys... The only thing anyone else has is the domain holder's public key... SSL itself remains in place as is... Sure, if you lose your private key - you're screwed -- but that's just owning up being a responsible domain owner.

Qantourisc 12y ago

DNS Dane, SSL singing with 2 CA's, peer-based trust, SSL pinning. We probably need a mix ... and none seems to be ideal. What would help is be more ruthless when CA's mess up, and no the pussy approach we are using now: do nothing.