Re: [MMUSIC] Thinking about best-effort encryption

[Eric Rescorla <ekr@xxxxxxxxxxxxxxxxxxxx>]

"Dan Wing" <dwing@xxxxxxxxx> writes:

>> You'll get very significant pushback from nework operators because 
>> of increase demand on proxies.
>>
>> It also means that it's unsecure at answer time.
>
> Er, I don't think so.  If you offer RTP/SAVP, and it's rejected by the
> answerer (called party), the called party's phone won't ring at all.
>
>> It's a valid mechanism, but I don't think it's  the best we can do.
>
> Due to HERFP, I consider re-inviting a mechanism that cannot work.  Unless
> we fix HERFP or deprecate forking.  
>
>> I think IKR is right:  we need to answer the very basic question 
>> about do we "HAVE to use SAVP" to mean best effort.
>> 
>> The draft that Hadriel and I did assume "No". 
>> Flemming's draft assume "Yes". 
>
> A correction: both drafts put RTP/AVP in the "m=" line.
>
> The offer in draft-andreasen-mmusic-sdp-capability-negotiation-01.txt, on
> page 16, is here (I show the interesting lines with "**"):
>
>            v=0 
>            o=- 25678 753849 IN IP4 128.96.41.1 
>            s=  
>            c=IN IP4 128.96.41.1 
>            t=0 0 
>      **    m=audio 3456 RTP/AVP 0 18  
>            a=sqn: 0 
>      **    a=cdsc: 1 audio RTP/AVP 0 18  
>      **    a=cdsc: 3 audio RTP/SAVP 0 18  
>            a=capar: 1 a=crypto:1 AES_CM_128_HMAC_SHA1_32    
>               inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32  
>            a=pcfg: c=3,4 a=1 
>            a=pcfg: c=1,2  
>
> The answer is described and shown on page 17:
>
>         Bob receives the SDP offer from Alice. Bob supports RTP, but not 
>         SRTP, and hence he accepts the potential configuration for RTP 
>         provided by Alice: 
>
>            v=0 
>            o=- 24351 621814 IN IP4 128.96.41.2 
>            s=  
>            c=IN IP4 128.96.41.2 
>            t=0 0 
>      **    m=audio 4567 RTP/AVP 0 18  
>            a=acfg: c=1,2 

Isn't that because it's not doing crypto in this example:

        Bob receives the SDP offer from Alice. Bob supports RTP, but not 
        SRTP, and hence he accepts the potential configuration for RTP 
        provided by Alice: 

I read this text form S 4.4.2. as implying that if the answerer
had been willing to do SRTP you would need RTP/SAVP in the m-line.


        If the answerer chooses to accept one of the alternative potential 
        configurations instead of the actual configuration, the answerer MUST 
        generate an answer as if the offer contained that potential 
        configuration instead of the actual configuration included. The 
        answerer MUST also include an actual configuration attribute in the 
        answer that identifies the potential configuration from the offer 
        used by the answerer. The actual configuration attribute in the 
        answer MUST include information about the capabilities. Furthermore, 
        if the offered potential configuration included attribute capability 
        parameters and/or transport protocol capabilities, those parameters 
        MUST be included in the actual configuration attribute in the answer 
        as well.  

But maybe I've just misunderstood Flemming's draft.

-Ekr