[asterisk-dev] DTLS setting impacts encryption setting

[Olle E. Johansson]

On 28 Jan 2014, at 21:25, Daniel Pocock <daniel at pocock.com.au> wrote:

> 
> This was on -users, but it appears all the DTLS discussion is on -dev so
> I'm reposting it...
> 
> 
> If I understand correctly, setting
> 
>   encryption=no
> 
> means that Asterisk will make outgoing calls without encryption, but
> will be happy to accept incoming calls regardless of whether the caller
> wants encryption or not (that is how it has been working for me anyway)
> 
> If encryption=yes, then Asterisk not only uses encryption for the
> outgoing calls but it will refuse to accept incoming calls unless they
> use encryption too.
> 
> If I have
> 
>   encryption=no
>   dtlsenable=yes
> 
> the DTLS support works but Asterisk will no longer accept incoming calls
> using regular RTP/AVP.  These messages appear in the console and the
> call is rejected with code 488:
> 
> [Jan 28 11:08:42] WARNING[24673][C-00000009]: chan_sip.c:10496
> process_sdp: Processed DTLS [FALSE]
> [Jan 28 11:08:42] WARNING[24673][C-00000009]: chan_sip.c:10529
> process_sdp: We are requesting SRTP for audio, but they responded
> without it!
> 
> I realise not everybody would set encryption=no in this situation, I'm
> simply trying to make it work for all possible callers to the
> SIP5060.net test numbers at http://www.sip5060.net/test-calls
> 
> Is this a bug or is there some reason that DTLS-SRTP can't allow the
> older behavior to continue?
> 

That seems to me like a bug. Please file a bug report in the issue tracker.

On the same note, I think in the light of the security discussions going on related
to pervasive monitoring we need to rethink a lot of the security concepts.
Previously I would say that we should not set up TLS connections without 
being able to verify the certificate. That's no longer the way I think - but
we need to clearly separate verified sessions where we can trust the identity
of the other part with sessions where we just encrypt without having a verified
identity. 

This will propably affect dialplans and configurations in new ways. We need to encourage
more encryption of media and signalling and separate that issue from authentication.

Now - my favorite question - what's a secure call?


/O