[dispatch] draft-davis-valverde-srtp-assurance [was: Re: IETF 117 - do you have something for DISPATCH?]

[Dan Wing <[e-mail]>]

Yeah, it feels like draft-davis-valverde-srtp-assurance could go straight to MMUSIC.

The I-D needs to discuss what happens when SSRC collision occurs, which I think is "send new SDP indicating the new SSRC and ROC=0".

I would like to understand where EKT-SRTP (RFC8870) fails to meet needs.  The design of EKT-SRTP avoids signaling SSRC or ROC in the signaling channel and, instead, allow them both to be indicated in the SRTP channel itself.  This design allows SSRC collisions to be handled very much like how they are handled with RTP (that is, without the "S").  I would rather see RFC8870 extended to work with SDP Security Descriptions because it moves us on a path towards DTLS-SRTP:  DTLS-SRTP-signaled endpoints could interop with SDP Security Descriptions-signaled endpoints because they're both using EKT to handle SSRC/ROC and key changes when group membership changes.  We really should be deprecating SDP Security Descriptions because it has far worse security properties compared with DTLS-SRTP.

-d


> Hi Kyzer (et. al.) -
> 
> Why aren't you taking this straight to mmusic? Am I missing something 
> that says that's not the obvious place for the work?
> 
> RjS
> 
> 
> On 6/27/23 7:31 AM, Kyzer Davis (kydavis) wrote:
> >
> > Hello,
> >
> > I would like to request a bit of dispatch time for the draft just posted:
> >
> > https://datatracker.ietf.org/doc/draft-davis-valverde-srtp-assurance/
> >
> > I also plan to attend IETF 117 in person to represent.
> >
> > Thanks,
> >
>