Re: [Ring] Future of platform-specific clients?

[Adonay Felipe Nogueira]

For the freedom issues referenced by Tirifto, see the whole thread in
[[https://lists.gnu.org/archive/html/libreplanet-discuss/2017-01/msg1.html]].
 Last
update was
[[https://lists.gnu.org/archive/html/libreplanet-discuss/2017-07/msg5.html]].
 But
no good conclusion was reached so far. Currently, the community assumes
the worst case scenario: QtWebEngine is considered non-free.

Re: [Ring] Future of platform-specific clients?

[Adrien Béraud]

Sorry, indeed I meant GNU/Linux distros ! 

On Android it's in the private app directory, 
that can be accessed with root on rooted devices, or using ADB when the app is 
in debug mode. 

It can be exported to other devices by using the "add a new device" feature. 
We plan to add a feature to export the account archive on public local storage 
soon, 
with a warning that it could then be sent on the network and bruteforced by 
other apps. 

Adrien 


De: "Stefan Monnier" <monn...@iro.umontreal.ca> 
À: "Adrien Béraud" <adrien.ber...@savoirfairelinux.com> 
Cc: ring@gnu.org 
Envoyé: Jeudi 22 Juin 2017 17:58:05 
Objet: Re: [Ring] Future of platform-specific clients? 

> On Linux account keys are in 

Do you mean GNU/Linux only or does that include Android as well? 

> .local/share/ring/{account_id} 

I can't find this on my Android phone (but then again, `find` under 
Android doesn't work too well, with all those inaccessible directories). 


Stefan 

Re: [Ring] Future of platform-specific clients?

[Stefan Monnier]

> On Linux account keys are in 

Do you mean GNU/Linux only or does that include Android as well?

> .local/share/ring/{account_id}

I can't find this on my Android phone (but then again, `find` under
Android doesn't work too well, with all those inaccessible directories).


Stefan

Re: [Ring] Future of platform-specific clients?

[Adrien Béraud]

Hi, 
Indeed a formal description of the protocol is much needed. 

We currently work on a first draft that you can see here: 
https://tuleap.ring.cx/plugins/mediawiki/wiki/ring/index.php/Protocol 
We are open to any comment, suggestion or criticism on the protocol itself or 
the way it is documented. 

About backup/restoration of Ring keys: 
It's not formally part of the network protocol, but it's also a important 
undocumented feature that we plan to address soon. 
Other implementations could use other mechanisms to protect access to 
cryptographic material. 

On Linux account keys are in 
.local/share/ring/{account_id} 
inside is: 
ring_device.crt : device certificate chain 
ring_device.key : private key corresponding to the device certificate public 
key 
(all standard x509 PEM) 
this is enough to place and receive calls if the device certificate is not 
revoked. 
export.gz : encrypted archive including the account certificate private key 
(allowing to sign/revoke device certificates). 
this file with the password is enough to "restore" a Ring account (generate a 
new device for this account). 
the archive is encrypted with AES-GCM-256 using the "Ring account password" 
hashed with argon2, 
that would indeed need to be documented. 

Regards, 

Adrien Béraud 
Ring project director, 
Savoir-faire Linux 


De: "Greg Troxel" <g...@lexort.com> 
À: "Anthony Léonard" <anthony.leon...@savoirfairelinux.com> 
Cc: ring@gnu.org 
Envoyé: Jeudi 22 Juin 2017 16:11:42 
Objet: Re: [Ring] Future of platform-specific clients? 

Anthony Léonard <anthony.leon...@savoirfairelinux.com> writes: 

> Hi, 
> 
>> It does not clearly give a oprotocol spec. 
> 
> Writing a protocol spec is a task still to be finished but is 
> definitely on the todo list. The protocol is not meant to be a 
> “walled garden” ;) 

Glad to hear it. I didn't mean to suggest ring was heading to walled 
garden - it's clear from the social context that this isn't true. Just 
that a protocol spec was missing and needed. 

One of the things the protocol spec will help with is discussion of the 
security model. I sent an earlier note about a concern with tracking 
via the dht. 

The other thing that could be discussed is exchange formats for 
exporting and importing ring account keys so that people can back them 
up and also use the same key on desktop and android, etc. 

>> and something RTP/ZRTP-ish to transport the bits. 
> 
> RTP inside a DTLS channel with Perfect Forward Secrecy encryption and 
> peers authenticating each other by their public keys. 

I see - so because you have the PK(non-I) already with the peers, you 
don't need to play the ZRTP game that would be used to get e2e 
confidentiality with regular SIP, and you can just use the peers' keys 
and also mix in an ephemeral key to get PFS. That makes total sense. 

Re: [Ring] Future of platform-specific clients?

[Greg Troxel]

Anthony Léonard  writes:

> Hi,
>
>> It does not clearly give a oprotocol spec.
>
> Writing a protocol spec is a task still to be finished but is
> definitely on the todo list. The protocol is not meant to be a 
> “walled garden” ;)

Glad to hear it.  I didn't mean to suggest ring was heading to walled
garden - it's clear from the social context that this isn't true.  Just
that a protocol spec was missing and needed.

One of the things the protocol spec will help with is discussion of the
security model.  I sent an earlier note about a concern with tracking
via the dht.

The other thing that could be discussed is exchange formats for
exporting and importing ring account keys so that people can back them
up and also use the same key on desktop and android, etc.

>> and something RTP/ZRTP-ish to transport the bits.
>
> RTP inside a DTLS channel with Perfect Forward Secrecy encryption and
> peers authenticating each other by their public keys.

I see - so because you have the PK(non-I) already with the peers, you
don't need to play the ZRTP game that would be used to get e2e
confidentiality with regular SIP, and you can just use the peers' keys
and also mix in an ephemeral key to get PFS.  That makes total sense.


signature.asc
Description: PGP signature

Re: [Ring] Future of platform-specific clients?

[Anthony Léonard]

Hi,

> It does not clearly give a oprotocol spec.

Writing a protocol spec is a task still to be finished but is
definitely on the todo list. The protocol is not meant to be a 
“walled garden” ;)

> If I'm following correctly, ring is opendht for discovery

Correct, it is also used to exchange messages when a SIP channel is not
established between two participants (when not in call). From a
security perspective, it is also used for public key sharing between
contacts so you can authenticate them before a call.

> something sip-like for bringing up a session with the
> peer once you find it.

Correct, it is SIP (using pjsip implementation) used in a peer-to-peer
manner (without the traditional SIP proxies/registrar infrastructure).

> probably some kind of STUN/TURN to deal with NAT

Yes, the ICE protocol is used which enables Ring to try different
methods to establish a connection, a direct link being preferred. TURN
servers (relays) are the last solution as it induces latencies so
others are tried before (such as hole-punching).

> and something RTP/ZRTP-ish to transport the bits.

RTP inside a DTLS channel with Perfect Forward Secrecy encryption and
peers authenticating each other by their public keys.

Best regards.

Anthony L.

signature.asc
Description: This is a digitally signed message part

Re: [Ring] Future of platform-specific clients?

[Greg Troxel]

There's a larger point in the discussion about plaform-specific clients,
which is the distinction between a protocol specification and an
implementation.

As I look at the ring.cx site, it talks about the implementation.  It
does not clearly give a oprotocol spec (something like you'd find in
IETF), so that someone could write an independent interoperable
implementation.  Successful protocols are either proprietary walled
gardens or have multiple independent implementations.  SIP and ZRTP, for
example, are the multiple implementation type.

If I'm following correctly, ring is opendht for discovery (which would
then have to be examined for protocol vs defined by a singleton
implementation), something sip-like for bringing up a session with the
peer once you find it, probably some kind of STUN/TURN to deal with NAT,
and something RTP/ZRTP-ish to transport the bits.

Re: [Ring] Future of platform-specific clients?

[Óvári]

Please integrate GNU Ring with CardBook:

https://addons.mozilla.org/thunderbird/addon/cardbook/

It is based on the vCard format and runs on multiple operating systems 
(Linux, Windows, Mac, BSD, ...)


The developer of CardBook is Philippe Vigneau who can be emailed at:

cardbook.thunderb...@gmail.com

Thank you

On 22/06/17 06:07, Anthony Léonard wrote:

Hi Adonay,


Last but not less important: I might be wrong on the following: One
of
the issues of using JavaScript might be the loss of integration with,
for example, vCard contact managers. But of course it's always better
to
ask a real expert instead of an occasional user and contributor (this
is
me). :)

You are half-right (or wrong, depends on your mood :) ). The
integration with third party contact managers (like GNOME Contacts on
GNU/Linux or Contacts app on MacOS) is currently managed by the client
layer on each platforms. The client "injects" contacts it gather from
external applications in its own contact list alongside the contacts
coming internally from the daemon.

The part on which you're wrong is that the loss of integration is not
related to JS itself but to the fact that an interface between a new
“ring-electron” client and contact managers is yet to be implemented.
It is not infeasible but requires making a wrapper in C/C++ for every
existing "contact-APIs" to expose those interfaces to JS code.

Another solution could be to integrate this support inside the
daemon, but also requires coding interfaces for each contact systems as
those interfaces are currently split between every clients.

Best regards.

Anthony L.