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

[Justin Uberti <[e-mail]>]

Agree with Cullen (and FWIW the SRTP encryption uses keys vended from the
DTLS master secret, so I think even if you are able to crack the SRTP
crypto it would not be trivial to go backwards up to the DTLS key material)


On Wed, Mar 5, 2014 at 2:35 PM, Cullen Jennings (fluffy)
<[e-mail]>wrote:

>
> On Mar 5, 2014, at 2:33 PM, tim panton <[e-mail]> wrote:
>
> >
> > 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.
>
> No - it does not weaken DTLS to know the plaintext (and if it did, DTLS
> would have series security problems )