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

[Roman Shpount <[e-mail]>]

Hi Brian,

Many people promote DTLS-SRTP, but DTLS-SRTP is not a fully featured
replacement for SDES-SRTP. The problem with DTLS-SRTP is it cannot reuse
the same pair of 5-tuples for two different sessions. To deprecate
SDES-SRTP, DTLS-SRTP should be enhanced to handle two DTLS handshakes over
the same transport address and a mechanism to associate these handshakes
with SSRC. DTLS-SRTP negotiation was patched up to work with WebRTC, but it
will not work for all the scenarios where SDES-SRTP is used. Without the
standard update, the most likely result of the DTLS-SRTP regulatory
requirements for Next Gen 9-1-1 would be that emergency calls will be
dropped. Also, considering the external dependency on TLS, I don't think
MMUSIC can add the required functionality on its own.

Best Regards,
_____________
Roman Shpount


On Tue, Aug 15, 2023 at 11:02 AM Brian Rosen <br=
[e-mail]> wrote:

> A piece of info that might affect the discussion of prolonging SDES vs
> DTLS-SRTP.
>
> In the US, the regulator announced an intention to require all carriers,
> including VoIP carriers to support “Next Generation 9-1-1” signaling.  That
> requires SIP with DTLS-SRTP.  The emergency call service side does not
> support SDES.  Of course, security is hop by hop, and nearly every carrier
> anchors media, so the DTLS-SRTP connection is likely from the carrier’s SBC
> to the emergency services SBC, and the phone could still support SDES, but
> it’s another nail in the SDES coffin.
>
> I would be opposed to enhancing SDES.  Implementing this draft would
> require code changes in the device that needed it.  I would prefer those
> changes implement DTLS-SRTP.  While I do recognize that the magnitude of a
> change to implement DTLS-SRTP, with EKT-SRTP would be much greater than
> implementing this draft on a device that implemented SDES, a change is a
> change, and I think the security of DTLS-SRTP is so much better than SDES,
> that I believe we should not encourage continuing deployment of SDES.
>
> Brian
>
>
>
> On Jul 17, 2023, at 5:09 PM, Kyzer Davis (kydavis) <kydavis=
> [e-mail]> wrote:
>
> Hello Dan,
>
> I reached out to the MMUSIC chairs (along with AVTCORE Chairs and Dispatch
> chairs CC’d)
> MMUSIC felt like it belonged but still wanted the dispatch time since
> there is no MMUSIC meeting at 117.
>
> To address a few other statements:
>
> > I would like to understand where EKT-SRTP (RFC8870) fails to meet needs.
>
> I think EKT-SRTP does a great job. That is, if we are using DTLS-SRTP. I
> am only aiming to do the same for SDP Security (SDES).
>
> > 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.
> I believe you are referencing the act of an SBC/B2BUA interoperating SDP
> Security and DTLS-SRTP w/EKT?
> I found some older EKT-SRTP drafts that I think are the topic:
> https://www.ietf.org/archive/id/draft-mcgrew-srtp-ekt-06.html#anchor6
> https://www.ietf.org/archive/id/draft-mcgrew-srtp-ekt-06.html#anchor21
>
> One point discussed in there was “SDP Security Descriptions however does
> not negotiate SSRCs and their associated Rollover Counter (ROC). Instead,
> SDES relies on a so-called "late binding", where a newly observed SSRC will
> have its crypto context initialized to a ROC value of zero. Clearly, this
> does not work for participants joining an SRTP session that has been
> established for a while and hence has a non-zero ROC.”
>
> If that is the point then I agree; having the SSRC, ROC, SEQ in SDES/SDP
> security could allow for an intermediary to easily interwork
> SDES<>DTLS-EKT-SRTP.
> Note: I would need to audit EKT-SRTP to see if there is anything else SDES
> is missing that could help that Key Management Interworking.
>
> > We really should be deprecating SDP Security Descriptions because it has
> far worse security properties compared with DTLS-SRTP.
> I also know SDP as a means for conveying keying material for SRTP isn't
> exactly the best method in the grand scheme when compared to the other
> available options.
> That being said, there are many millions of devices across different
> vendors still using SDP Security as the SRTP key management protocol.
> Further, I continue to see more modern internet telephony service
> providers providing TLS SIP w/SRTP via SDES and the acceleration of cloud
> registered SIP endpoints utilizing SDP Security.
> Ignoring the problem that could positively affect so many does not seem
> like the right thing to do.
>
> Other:
> I started an audit of various enterprise, cloud and service provider
> offerings to compare MIKEY, DTLS-SRTP, EKT-SRTP, and SDP Security but I
> will not be able to finish this by the time for dispatch so I have dropped
> the slide. I can create a wiki page on the drafts GitHub if the group wants
> to help crowdsource a “Current State of SRTP Key Management Protocol
> offerings in 2023”. Similarly, if a similar study already exists I would
> love to give it a read.
>
> Lastly, I have a WIP draft-01 which provides an alternative solution to
> draft-00’s a=srtpctx SDP attribute.
> The alternative solution reuses the sdp security session parameter postfix
> options to convey SSRC, ROC, SEQ.
>
> https://www.iana.org/assignments/sdp-security-descriptions/sdp-security-descriptions.xhtml#sdp-security-descriptions-4
> I plan to have a slide on both solutions for the dispatch discussion.
>
> Thanks,
>
> *From:* Dan Wing <[e-mail]>
> *Sent:* Monday, July 17, 2023 3:41 PM
> *To:* [e-mail]
> *Cc:* Kyzer Davis (kydavis) <[e-mail]>; Robert Sparks <
> [e-mail]>; [e-mail]
> *Subject:* draft-davis-valverde-srtp-assurance [was: Re: [dispatch] IETF
> 117 - do you have something for DISPATCH?]
>
> 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,
>
> >
>
>
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>