Re: [Linphone-developers] Lots Of Configuration Questions.

[Simon MORLAT]

Hi David,

Sorry again for my belated answer. We had a lot of uncertainties to manage with iOS10 changes.

Let me respond to your points. After that I think it will be good that we propose your a commercial development/assistance program with Belledonne Communications so that you can receive answers with a quicker turnaround, and with more details.

1. Yes this is the default configuration to use hmac signature.

3. This checkbox is indeed buggy. I just pushed a fix for this. Encryption mandatory is available for all encryption mechanisms. Since ZRTP is discovered when the call is established, it will have the effect of silencing the call completely, so that no clear text data is emitted. Note that the encryption status is available in the incall view, in the form of a small pictogram representing a lock.

6. By secret validity period I meant that the keys stored in the zrtp cache don't have any expiration date in the current implementation. However, the AES keys used for the communication are unique per call, and not stored anywhere. I believe there is no way to decrypt a stream a posteriori even if a ZRTP cache is disclosed.

6.1. The goal of the call is to make a key exchange between the two clients with a man in the middle verification (thanks to the ZRTP SAS code procedure made by the two participants).

Without ZRTP SAS, there is no MIM verification. A possible way of improvements we are thinking about would be to indeed make a kind of "silent" call, invisible to users, so that the key exchange is made when the first IM message is sent. The MIM verification can be done later with a real call.

However there is no magic, you cannot make a MIM verification without using an alternate channel and involving the users directly.

7. Composition indication is implemented in the library using RFC3994. I don't understand what you mean by "pixmaps". There is no way to turn it off "per user" currently.

8. I meant that the application doesn't make use of this feature (like many many others actually). Using it means adding the button to UI and associated function calls in the application source code so that the feature becomes activable and configurable from the app standpoint.

9. Making a p2p file transfer requires that both clients are simultaneously connected to the network with reasonable usable bandwidth, which is not always the case.

This is why a store-and-forward model is much more convenient. This is absolutely not a security risk since LIME will encrypt the file before it is deposited on the server, with the key required for the receiver.

Best regards,

Simon

2016-09-18 23:06 GMT+02:00 David Heath <address@hidden>:

Alright, thank you for writing back to me. I will ask a few follow-up questions related to my own needs and information I believe should be documented in the interest of public understanding. I apologise if this is difficult to read but I have not been able to figure out how to use your convenient reply format.

1: I believe you are correct. Is this configuration default? Are the other best-practice implementations discussed on that page already incorporated into Linphone?

2: Understood. I will look into MIKEY myself at a later date if necessary.

3: This is somewhat concerning. The checkbox is clickable in GUI when DTLS is selected, which seems to provide a false sense of security. I don't know how the code is arranged but this interface logic seems inappropriate. Users need the option to specify allowed/required methods in order of preference by default (globally), per server/network, and per contact. This may be easiest to implement in a configuration file for the time being but I would really like to see it in the GUI, at least until SIP encryption methods are more standardised. Encryption status should be displayed on the main window, perhaps unobtrusively at the bottom, and users should be actively notified of potential down-grade events, either resulting from an attack or technical malfunction.

4: That is perfect, thank you. I assume the negotiation prefers the first method to appear and methods not listed will never be accepted. As per the previous topic three, session encryption methods could be configured in the same manner.

6: Ok, I have read about LIME but my understanding of programming and cryptography is fairly poor. If LIME is used for text messages and ZRTP is used for voice/video, do they share the same ZRTP cache? I understand that "secret validity period is not yet implemented" means that there is currently no provision for forward secrecy. This is probably not an urgent priority but I hope it is still on your radar. I actually prefer LIME's similarity to ZRTP over OTR from a logistical standpoint but, assuming LIME is not compatible with OTR, perhaps it would be worth implementing OTR for compatibility since it seems to be the preferred method for other SIP clients.

6.1: I understand that LIME will not actually encrypt anything until the first voice/video call is transacted; this is a significant down-side for users without the technical means to field the initial call, or who would prefer to conduct a conversation exclusively through text. I presume some voice/video data is used to seed the initial encryption key, which would render encryption useless if, for example, the call were muted due to user ignorance; perhaps you could provide a feature to hash this from a different random source and exchange the keys silently and transparently to the users?

7: Composition indication seems to be implemented through "pixmaps", which appears in Linphone's GitHub. Again, I am not a programmer but I would assume this means message composition is supported in Linphone but not through Liblinphone. That said, the feature list for Liblinphone does say that it supports RFC3994. Is this what you meant by "works independently"? Regardless of how it is implemented, I think it would be good to provide for configuration in the same manner as presence in the GUI, since they are logically similar. This is obviously not a priority but some people may not want to let certain contacts know when they are typing, or perhaps they do not want to let anyone know when they are typing. It is a matter of personal _expression_ so it will have implications on user comfort.

8: I understand that Linphone does use Liblinphone. Does "library only feature" mean users need to configure it in the library source code, compile the new library, and then install it? Which header is used in the software available to users on your website?

9: So this would also need to be configured, compiled, and reinstalled to enable/disable, but it is enabled in the software on your website? Do you actually use the method I provided? I found a link (included below) that says you use HTTP as described in section 3.5.4.8 of GSMA's Rich Communications Service P.D.F. Perhaps the information I found is out of date but this method is very different since "...the file transfer is based in [sic] storing the file in a publicly available server and then sharing the location using standalone messaging...". If I understand this correctly, it would mean file transfers are never P2P and may be terribly insecure, depending on what server is used and how it is configured. Perhaps you serve the file from a local HTTPS socket?

Link: https://linphone.org/dokuwiki/doku.php/liblinphone:file_transfer

On 15 September 2016 at 12:58, Simon MORLAT <address@hidden> wrote:

Hi David,

Please find below my answers for some of your questions, inlined below.

1: In my research, I found a link that says "...integrity protection might not be used" for SRTP, which I understand is used as the basis of all popular SIP encryption methods. Is this something to be concerned about? There are also a few other points of interest for implementation of non-ZRTP methods but they may be common knowledge.

Here is the link: http://crypto.stackexchange.com/questions/35163/what-are-the-pros-and-cons-of-sip-media-encryption-types-srtp-zrtp-and-dtls

I think that it refers to the fact that packet hmac is optional in SRTP. However its presence is negociated by clients within the SDP offer/answer model. It is only a matter of client configuration to decide that hmac is mandatory.

 

2: According to Wikipedia, MIKEY (rfc-3830) can be used to determine session keys for use with SRTP. Is this used only for 3DES or also for DTLS? Would both clients need to be specifically configured to use MIKEY? I don't know if this is beneficial or perhaps already default but it is interesting to me because I have not heard of it before.

I have no experience with mikey, unfortunately.

 

3: In Linphone GUI, when I select ZRTP the "Media encryption is mandatory" checkbox becomes unclickable. Is this because ZRTP is opportunistic? I would like this to be required, or at least required for contacts who have used it before. I imagine that, without this requirement, down-grade attacks would be possible. I might also like to configure DTLS to be required when ZRTP is not available but this does not appear to be possible from the GUI. Are these sort of settings normally configured in a text file?

Actually "media encryption mandatory" only works for normal SRTP (SDES), so that the call is declined if the other party doesn't support SRTP.

 

4: How can I specify which key exchange methods should be allowed, which should not be allowed, and the priority in which the methods should be preferred?

From the linphonerc config file you can specify the supported SRTP profiles, for example:

 [sip]

srtp_crypto_suites=AES_CM_128_HMAC_SHA1_80, AES_CM_128_HMAC_SHA1_32, AES_256_CM_HMAC_SHA1_80, AES_256_CM_HMAC_SHA1_32

 

5: IPv6 is very intimidating for a number of reasons but why is the option to allow it disabled by default? I understand it is usually not necessary but is there some risk associated with its use? If IPv6 traffic is allowed, does that mean it is preferred by Linphone?

If IPv6 is allowed and the SIP server to which Linphone is registering has an IPv6 in DNS, then IPv6 will be prefered indeed.

There is no risk theoritically but unfortunately we see that IPv6 is not working well with certain routers or dsl boxes, despite devices are provided with IPv6 addresses.

Turning if off will, in such cases

 

6: Is text messaging handled through MSRP and CEMA? Are there provisions for end-to-end encryption, such as O.T.R.?

Messaging is handled by SIP MESSAGE request. We have our own end to end encryption called LIME, that is based on ZRTP for key exchange and MITM verification.

This is a feature in the library that is not exposed in the UIs for the moment.

 

7: I understand Linphone supports R.F.C. 3994 (indication of composition) and 3856 (presence) but do these rely on an intermediary server or do they also function normally in P2P? When adding a contact, there are options to configure presence but not indication of composition; this seems a bit strange since they are similar in nature. Are the settings for indication of composition also available per contact?

Presence can work p2p without the assistance of a presence server. It is configured by enabling presence subscription on LinphoneFriends (ie contacts).

Composition indication works independently and I think cannot be turned off.

 

 

8: Liblinphone seems to support rfc-3323 through "enum _LinphonePrivacy" but I could not find relevant settings in the Linphone GUI. How should I configure my client on Windows or Linux?

This is a library only feature.

 

9: Is it possible to broker file transfers through SIP with Linphone? I found an interesting I.E.T.F. draft and I suspect this approach has been assumed by the Blink client software, though I cannot confirm. Here is a link to the draft: https://tools.ietf.org/html/draft-ietf-mmusic-file-transfer-mech-11

The file transfer is supported in iOS and Android apps. It is indeed supported in desktop edition. This is a feature implemented in the library.

Best regards,

Simon 

Those are all of my questions for now but I would also like to provide a quick commentary on some of the messaging clients I have recently tested. Jitsi makes security easy with options for DNSSEC and Tor binding. Blink advertises screen sharing and file transfers. Wire advertises decentralised service and simple account creation. Telepathy advertises VNC integration and Pidgin advertises support for numerous communication protocols/services. Obviously many of these features would be practically impossible to build into Linphone but I wanted to mention them all in one place since they are all good features. If it is ever convenient to build any of them into Linphone, I think they would be useful.

Thanks for reading if you're gotten this far!

_______________________________________________
Linphone-developers mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/linphone-developers

_______________________________________________
Linphone-developers mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/linphone-developers

_______________________________________________
Linphone-developers mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/linphone-developers