Summary:	ASTERISK-26701: res_pjsip_sdp_rtp: Optimistic Encryption Doesn't Recognize DTLS fingerprint
Reporter:	Joshua Elson (joshelson)	Labels:
Date Opened:	2017-01-06 21:04:58.000-0600	Date Closed:
Priority:	Major	Regression?
Status:	Open/New	Components:	Resources/res_pjsip_sdp_rtp
Versions:	13.13.1	Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Optimistic encryption on Asterisk 13+ doesn't properly recognize a DTLS "fingerprint" line in the SDP, and therefore will not properly negotiate DTLS on an incoming call to Asterisk. Patch forthcoming to resolve this issue.
Comments:	By: Asterisk Team (asteriskteam) 2017-01-06 21:04:59.840-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Rusty Newton (rnewton) 2017-01-08 17:42:07.429-0600 Thanks Joshua! By: JoshE (n8ideas) 2017-01-18 00:52:52.553-0600 @jcolp - apologies on this taking so long to get back to you on, but I opened a larger can of worms than expected in trying to resolve this. I think some of this breaks down to a semantic difference between what was intended in the meaning of "optional" encryption and "optimistic" encryption. Essentially, media_encryption_optimistic really is an implementation of optional SDES, rather than an attempt to encrypt all the things when we see offerer SDP we know supports it. This is predominately written and researched to address our use case - where Asterisk is in the answerer position, but there are additional and similar questions raised when Asterisk is offerer. There are really two things I'd like to be able to do that are currently unsupported. Maybe we can break this into things that more resemble defects and those that are true net new functionality (or I'll at least make my arguments on these :) ).  Our issues: 1) Optional DTLS is not supported. Therefore, an offer with RTP/AVP and also a fingerprint line is not processed properly. This is near certainly a new feature, though the documentation is poor with respect to what optional encryption actually means in currently released software. It is not immediately clear without reading source that this was only designed to support SDES. 2) media_encryption_optimistic doesn't work as expected in all cases. I have a need to support SDES, DTLS, and unencrypted media concurrently on the same endpoint, and I would expect that to work with media_encryption=none and media_encryption_optimistic=yes. This is especially important for those of us migrating to WebRTC applications where DTLS is mandatory to implement. In my view, a mandatory DTLS offer should allow the "upgrade" of the encryption for the call where media_encryption_optimistic=yes and media_encryption != dtls, in the case that all other endpoint settings (cipher, certificates, etc...) are there. While I [now] understand the original design intent, optimistically checking for both SDES and DTLS seems more proper to me. This is, arguably, something more like a defect, depending on how strictly you interpret the intent versus expectations with multiple crypto options. There are three things that would need to be changed to support both of the above, from what I can see: 1) pjsip_configuration doesn't allow for DTLS to be enabled in the RTP engine based on the "optimistic" notion of media encryption, which will cause the local fingerprint to fail to generate. This is fairly easy to resolve in the endpoint configuration itself by just allowing otherwise properly configured endpoints from a DTLS perspective to enable DTLS when optimistic encryption is enabled. 2) There's an entanglement of use received transport settings in bootstrapping some required configuration. That really needs to be undone so that the notion of transport isn't attached to the use of optimistic encryption, though there may be some additional discussion required on the intent of received transport in this respect. In my view, you should be able to predictably toggle media_encryption_optimistic regardless of how you want to handle other transport settings and get the same behavior with respect to encryption. 3) The pjsip SDP handler needs some modifications to properly note all the different optimistic possibilities mentioned above, depending on how we wanted to support them. Possible solutions: 1) Alter media_encryption_optimistic to behave more like what I'd expect. Optimistically encrypt, and prefer "better" encryption in DTLS over SDES if presented with both. Always enforce the minimum encryption level as defined in media_encryption, presuming none < SDES < DTLS in terms of our optimistic preference (ie, offerer with media_encryption=dtls with media_encryption_optimistic=yes would be rejected if SDES crypto line was presented). 2) New config knob(s) could be created. We could have a media_encryption_dtls_optimistic option to allow for someone to separately toggle DTLS settings. This introduces additional configuration work and complexity in the media handler, and then you'd need to answer additional questions about how to interpret a new set of possibilities, such as media_encryption_optimistic=yes and media_encryption_optimistic_dtls=yes, especially in the case where you may receive both DTLS and SDES offers. 3) The configuration choices of media_encryption_optimistic itself could be extended. Rather than supporting simply 'yes' or 'no', we could add 'all', 'sdes', and 'dtls' (or something similar) to the allowable options list. Leave the behaviors as expected for existing configurations, so we're not changing behavior for people that have existing configurations, but allow people that want to implement a more precise definition of what optimistic encryption means for them to do so. There may be additional things to think about with Asterisk in the offerer position, though that's not our primary use case. Seems like Asterisk could be extended predictably to offer DTLS on endpoints that have the configuration for it, where media_encryption=none or media_encryption=sdes with where media_encryption_optimistic=yes would generate fingerprint and/or crypto lines. The worry there could be that interoperability with other implementations of this functionality could be difficult to predict. Not sure what your perspective on this would be and what limitations there are on changing functionality like this mid-version, but this is a high priority for us. We'd be willing to implement and write tests for any one of these options. Would be good to get a sense on what would be the best solution from your point of view. Happy to further clarify or supply the code changes we've made to resolve this for our use cases, if that's helpful to you. Josh By: Joshua C. Colp (jcolp) 2017-01-18 05:47:29.585-0600 Provided tests are written and existing behavior works then this could occur in a release branch. If the behavior changes given the same configuration or tests fail then it would be a no-go. As for received transport it exists to support the scenario where optimistic is turned on but you receive an offer with required encryption. If the transport is not matched in the SDP the negotiation will fail and the call will fail. Extending the choices of media_encryption_optimistic is best - as long as the existing options remain and behave as they do now. I'm not against any of this, we just have to ensure that what exists now is not broken as a result and that the functionality is fully flushed out. Outside the scope of SDP being the offerer the current RTP support may not allow this. It's not written to support both DTLS and SDES on an instance and I'm not sure if it would work. It would be something to make sure of.