[asterisk-bugs] [JIRA] (ASTERISK-26701) res_pjsip_sdp_rtp: Optimistic Encryption Doesn't Recognize DTLS fingerprint

[JoshE (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234693#comment-234693 ] 

JoshE commented on ASTERISK-26701:
----------------------------------

@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

> res_pjsip_sdp_rtp: Optimistic Encryption Doesn't Recognize DTLS fingerprint
> ---------------------------------------------------------------------------
>
>                 Key: ASTERISK-26701
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26701
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip_sdp_rtp
>    Affects Versions: 13.13.1
>            Reporter: Joshua Elson
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)