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

["Kyzer Davis (kydavis)" <[e-mail]>]

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-desc
riptions.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/>
https://datatracker.ietf.org/doc/draft-davis-valverde-srtp-assurance/
> 
> I also plan to attend IETF 117 in person to represent.
> 
> Thanks,
>