Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level

[tim panton <[e-mail]>]

On 5 Mar 2014, at 14:25, Justin Uberti <[e-mail]> wrote:

> So there are three things here:
> 1) MUST the implementation offer encrypted header extensions? (i.e. mandatory-to-implement)
> 2) MUST the implementation use encrypted header extensions? (i.e. mandatory-to-use)
> 3) MUST the implementation expose an API to control this? (i.e. no SDP munging needed)
> 
> I think we want yes for #1, no for #2, and #3 is potentially interesting but out of scope for 1.0.
> That gives encrypted headers for audio on by default, but remote parties can negotiate this off using RFC 6904 mechanisms.
> 

In order to agree with that I’d need to be persuaded that there isn’t a known-plaintext attack risk there
(e.g. detecting a muted mic therefore knowing the ulaw content of a packet), since
any weakening  in DTLS also impacts the data channel and video channels - assuming bundle.

Like I say, I’m not enough of a cryptographer to know.

T.