4 ms·

Ring-KDE announcment: https://elv13.wordpress.com/2015/05/07/announcing-ring-a-distributed-and-secure-multimedia-communication-platform/ https://elv13.wordpress

by Elv13 11y ago

Ring-KDE announcment: https://elv13.wordpress.com/2015/05/07/announcing-ring-a-distributed-and-secure-multimedia-communication-platform/ https://elv13.wordpress.com/2015/05/07/announcing-ring-a-dis... (I am one of the developer, ask me anything) EDIT: There is screenshots on that page

madez 11y ago
As I asked in my direct comment on this submission: What are the advantages compared to Tox? I see one advantage of Tox compared to Jitsi. Account management is decentralized on Tox and federated on the protocols Jitsi supports. Are there plans to support Tox as a backend?
- Elv13 11y ago
  As of now we have no plan to support Tox. We initially evaluated this and decided against. Ring is based on open standards such as SIP (rfc3261), TLSv1.2 (rfc5246), SRTP (rfc3711), vCards (rfc6350) and many more. We are also inter-operable with existing SIP infrastructure such as corporate phone system and classical phone provider with optional SIP accounts. We will continue to be as standard compliant as we can rather than create/support yet another custom communication protocol. What Ring bring to this existing mesh of technologies is the ability to connect people using a decentralized peer-to-peer network.
  - madez 11y ago
    Support for non-obsolete and secure standardized protocols seems to me to be a good thing. As of now we have no plan to support Tox. We initially evaluated this and decided against. I'm rather interested in the reasons of this decision. Ring is based on open standards (...). Tox is open as well. However, I see a difference between the protocols you've given and Tox: Tox is not standardized. What Ring bring to this existing mesh of technologies is the ability to connect people using a decentralized peer-to-peer network. This technology for peer-to-peer discovery is also not standardized, I assume. So, why creating your own protocol instead of using Tox for this?
    - Elv13 11y ago
      > This technology for peer-to-peer discovery is also not standardized, I assume. DHT has been used in the wild for more than a decade now, it is very well understood. SIP over DHT idea has also been studied[1] academically for a long period of time, even if it was never really implemented in commercial products. Finally, our P2P "protocol" is still using the standards mentioned above for cryptographic identity and other negotiation details, so there is very little that isn't fully standard. [1] Example: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.183.4313&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.183... (not used for the current Ring implementation)
      - madez 11y ago
        DHT has been used in the wild for more than a decade now, it is very well understood. Tox also uses DHT for contact discovery [1]. Does Ring support communication without having to register any type of account on any third-party server? [1]: https://jenkins.libtoxcore.so/job/Technical_Report/lastSuccessfulBuild/artifact/tox.pdf/ https://jenkins.libtoxcore.so/job/Technical_Report/lastSucce...
        Elv13 11y ago
        No server account are required, it is what DHT is for. However, if you do have a server SIP account, we also support them. This is all about interoperability with existing infrastructure.
        madez 11y ago
        I see value in the support of server accounts. However, the DHT-based account-less p2p part seems to redoing work Tox has done. Why not use their efforts and experience? They offer their core separately and Ring could be a client for it.
        Elv13 11y ago
        That would duplicate most of our code and we chose not to do so. We currently have an unified architecture that handle both existing sip infrastructure and the distributed one. The distributed part is less or more done, it isn't a big part of the code (about 4% according to a quick rexgex) compared to SIP. We currently use an open network model, but will switch to a closed one based on the cryptographic chain of trust in the coming weeks. That about all there is to it, everything else is SIP/ICE/UPnP/TLS/RTP.
- Nabuka 11y ago
  @madez: can you explain how you decide that decentralized account management is an advantage on federated?
  - Elv13 11y ago
    If I may give my take on this: Federated: Provide a little better anonymity as many operations are done behind firewalls/NAT/VPNs rather than using public data and point to point sockets. However it has a single point of failure for each nodes and switching from one federated node to another is either problematic or impossible. The federated node can also fall and shut down at anytime. Distributed: Doesn't required accounts. Base identity on cryptography rather than a web service. It use point to point or point to proxy to point communication. Some meta datas, such who talk to who, when and for how much time are available to anyone (cough...) who can tap on ISP connection metadatas. This service is more robust and cannot really be taken down in ways that cannot be fixed. Ring support both federated SIP networks and the distributed DHT network (and a mix of both). (the anonymity problem can be mitigated using tor like onion routing for the negotiation, but it is unrealistic to use real time communication over an onion network. [D]DOS attacks can be handled in a variety of ways, so are DHT trashing ones, bittorrent is still alive and well).
BuildTheRobots 11y ago
> The ZRTP encryption mechanism is no longer supported (please use TLS+SRTP) I thought SRTP used certificates rather than the diffie-hellman handshake used by ZRTP -or to put it another way, doesn't this destroy forward secrecy?
- Elv13 11y ago
  ZRTP may be back at some point. We had to disable it because of dependency issues (we switched to LibAV from CCRTP due to a long string of stability problems and constant regressions, not what you want for a network facing library). While you are right that this open the door to MiM attacks, this can be mitigated by certificate pinning and should be mostly fixed once we switch to a closed network (see some comments below). As it is implemented now, it all depend on how you transmit the Ring hash. This hash is the public key id, so if, for example, you double click on a Google contact with a Ring "phone number", the problem doesn't exist. So, all in all, a mix of trusted hash distribution, certificate pining and chain of trust should eliminate the problem from all angles. Again, this is work in progress (remember, this is an alpha) and ZRTP may come back if we get the resources/contribution to implement it in LibAV.
  - BuildTheRobots 11y ago
    Thank you for the detailed reply. Can I confirm that without ZRTP, or rather, with the current implementation, there's no forward secrecy; so should the keys get compromised either through technological or legal attack, all bets are off?
    - Elv13 11y ago
      Well, if you lose your private key and it get into their hand, as of now, yes, you can be impersonalized. As for perfect forward secrecy, it will be enabled sooner or later. We currently don't handle the case where your computer itself get compromised and the disk content is made available. Those scenario should be handled by encrypting your devices and sandboxing network facing applications. In Linux, we also use DBus as the main IPC between the client and the daemon. Anyone with root access could theoretically mess with it and do a local MiM attack. There is little any application can do about this kind of compromission so it is kind of pointless to try to tackle them. At best it would slow such an attack, at worst give a false sense of security.

by Elv13 11y ago

madez 11y ago

As I asked in my direct comment on this submission: What are the advantages compared to Tox? I see one advantage of Tox compared to Jitsi. Account management is decentralized on Tox and federated on the protocols Jitsi supports. Are there plans to support Tox as a backend?

Elv13 11y ago
As of now we have no plan to support Tox. We initially evaluated this and decided against. Ring is based on open standards such as SIP (rfc3261), TLSv1.2 (rfc5246), SRTP (rfc3711), vCards (rfc6350) and many more. We are also inter-operable with existing SIP infrastructure such as corporate phone system and classical phone provider with optional SIP accounts. We will continue to be as standard compliant as we can rather than create/support yet another custom communication protocol. What Ring bring to this existing mesh of technologies is the ability to connect people using a decentralized peer-to-peer network.
- madez 11y ago
  Support for non-obsolete and secure standardized protocols seems to me to be a good thing. As of now we have no plan to support Tox. We initially evaluated this and decided against. I'm rather interested in the reasons of this decision. Ring is based on open standards (...). Tox is open as well. However, I see a difference between the protocols you've given and Tox: Tox is not standardized. What Ring bring to this existing mesh of technologies is the ability to connect people using a decentralized peer-to-peer network. This technology for peer-to-peer discovery is also not standardized, I assume. So, why creating your own protocol instead of using Tox for this?
  - Elv13 11y ago
    > This technology for peer-to-peer discovery is also not standardized, I assume. DHT has been used in the wild for more than a decade now, it is very well understood. SIP over DHT idea has also been studied[1] academically for a long period of time, even if it was never really implemented in commercial products. Finally, our P2P "protocol" is still using the standards mentioned above for cryptographic identity and other negotiation details, so there is very little that isn't fully standard. [1] Example: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.183.4313&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.183... (not used for the current Ring implementation)
    - madez 11y ago
      DHT has been used in the wild for more than a decade now, it is very well understood. Tox also uses DHT for contact discovery [1]. Does Ring support communication without having to register any type of account on any third-party server? [1]: https://jenkins.libtoxcore.so/job/Technical_Report/lastSuccessfulBuild/artifact/tox.pdf/ https://jenkins.libtoxcore.so/job/Technical_Report/lastSucce...
      - Elv13 11y ago
        No server account are required, it is what DHT is for. However, if you do have a server SIP account, we also support them. This is all about interoperability with existing infrastructure.
        madez 11y ago
        I see value in the support of server accounts. However, the DHT-based account-less p2p part seems to redoing work Tox has done. Why not use their efforts and experience? They offer their core separately and Ring could be a client for it.
        Elv13 11y ago
        That would duplicate most of our code and we chose not to do so. We currently have an unified architecture that handle both existing sip infrastructure and the distributed one. The distributed part is less or more done, it isn't a big part of the code (about 4% according to a quick rexgex) compared to SIP. We currently use an open network model, but will switch to a closed one based on the cryptographic chain of trust in the coming weeks. That about all there is to it, everything else is SIP/ICE/UPnP/TLS/RTP.
Nabuka 11y ago
@madez: can you explain how you decide that decentralized account management is an advantage on federated?
- Elv13 11y ago
  If I may give my take on this: Federated: Provide a little better anonymity as many operations are done behind firewalls/NAT/VPNs rather than using public data and point to point sockets. However it has a single point of failure for each nodes and switching from one federated node to another is either problematic or impossible. The federated node can also fall and shut down at anytime. Distributed: Doesn't required accounts. Base identity on cryptography rather than a web service. It use point to point or point to proxy to point communication. Some meta datas, such who talk to who, when and for how much time are available to anyone (cough...) who can tap on ISP connection metadatas. This service is more robust and cannot really be taken down in ways that cannot be fixed. Ring support both federated SIP networks and the distributed DHT network (and a mix of both). (the anonymity problem can be mitigated using tor like onion routing for the negotiation, but it is unrealistic to use real time communication over an onion network. [D]DOS attacks can be handled in a variety of ways, so are DHT trashing ones, bittorrent is still alive and well).

BuildTheRobots 11y ago

> The ZRTP encryption mechanism is no longer supported (please use TLS+SRTP) I thought SRTP used certificates rather than the diffie-hellman handshake used by ZRTP -or to put it another way, doesn't this destroy forward secrecy?

Elv13 11y ago
ZRTP may be back at some point. We had to disable it because of dependency issues (we switched to LibAV from CCRTP due to a long string of stability problems and constant regressions, not what you want for a network facing library). While you are right that this open the door to MiM attacks, this can be mitigated by certificate pinning and should be mostly fixed once we switch to a closed network (see some comments below). As it is implemented now, it all depend on how you transmit the Ring hash. This hash is the public key id, so if, for example, you double click on a Google contact with a Ring "phone number", the problem doesn't exist. So, all in all, a mix of trusted hash distribution, certificate pining and chain of trust should eliminate the problem from all angles. Again, this is work in progress (remember, this is an alpha) and ZRTP may come back if we get the resources/contribution to implement it in LibAV.
- BuildTheRobots 11y ago
  Thank you for the detailed reply. Can I confirm that without ZRTP, or rather, with the current implementation, there's no forward secrecy; so should the keys get compromised either through technological or legal attack, all bets are off?
  - Elv13 11y ago
    Well, if you lose your private key and it get into their hand, as of now, yes, you can be impersonalized. As for perfect forward secrecy, it will be enabled sooner or later. We currently don't handle the case where your computer itself get compromised and the disk content is made available. Those scenario should be handled by encrypting your devices and sandboxing network facing applications. In Linux, we also use DBus as the main IPC between the client and the daemon. Anyone with root access could theoretically mess with it and do a local MiM attack. There is little any application can do about this kind of compromission so it is kind of pointless to try to tackle them. At best it would slow such an attack, at worst give a false sense of security.