Does double encryption matter for (say) SAVPF?

SpencerDawkins / sdp-rtp-quic-issues

Issued gathered from a variety of uncoordinated places, for sanity's sake.

Other

0 stars 0 forks source link

Does double encryption matter for (say) SAVPF? #5

Open SpencerDawkins opened 3 years ago

SpencerDawkins commented 3 years ago

RTP (and RTCP) headers and payloads will be entirely encrypted using QUIC ({{RFC9000}}), as secured by TLS 1.3 handshake ({{RFC9001}}), between QUIC endpoints. It's worth thinking more about how that maps onto expected deployment scenarios like centralized multiparty conferencing, and also whether WebRTC really requires SAVPF with double encryption (i.e. SRTP encryption, and then QUIC encryption). No opinions here yet, just noting the question for now.

SpencerDawkins commented 3 years ago

From @rjb1000, Richard Bradbury, via private email:

Is QUIC/RTP/SAVP the right profile name? I wonder if SRTP (as specified in RFC 3711) is rendered obsolete by QUIC given that the latter satisfies the primary security goals of SRTP (confidentiality and integrity). Isn't the simple case really just QUIC/RTP/AVP? That then begs the question: What is the difference between QUIC/RTP/AVPF and QUIC/RTP/SAVPF, given that security is built into the QUIC transport.

SpencerDawkins commented 3 years ago

ISTM that the answer to these questions depends a great deal on how much effort we expect people to go to, in order to run "RTP over QUIC", and that likely doesn't have a single answer. If a SIP implementation is using RTP/SAVPF today, and is using endpoints that also support QUIC, QUIC/RTP/SAVPF might be appealing (and might allow the use of QUIC/RTP/SAVPF in multipoint conferencing scenarios where some endpoints use QUIC/RTP/SAVPF, and others use RTP/SAVPF).

In other scenarios, the assertion that QUIC/RTP/AVPF and RTP/SAVPF provide roughly equivalent protection, so double encryption with QUIC/RTP/SAVPF isn't adding anything, might be attractive. This is definitely an issue that needs more discussion (and, not necessarily, in the context of this draft!)

juberti commented 2 years ago

I'd argue that double encryption is a clear negative, since you'll have 2 HMACs and thereby at least 10 wasted bytes per packet.

SpencerDawkins commented 2 years ago

Adding a note from @juberti on the AVTCORE mailing list about this:

I think the security aspects discussed in Section 1.5 are a good example of this. At first glance, QUIC/RTP/SAVPF feels a lot like the UDP/TLS/RTP/SAVPF defined in https://www.rfc-editor.org/rfc/rfc5764.html, but the semantics are much different, namely: 1) The SRTP encryption process is not used, and instead QUIC's encryption and encapsulation process is used. 2) The SAVPF profile is meant to be a hint to downstream consumers, per Section 1.5, rather than a difference in the wire format.

I think it would be good to align with the precedent set in https://www.rfc-editor.org/rfc/rfc7850.html, which indicates that the right profile in all cases would be QUIC/RTP/AVPF. Any behaviors required of the middlebox seem like they should be indicated by some other explicit attribute given the ambiguity associated with overloading the profile.

SpencerDawkins commented 2 years ago

@rjb1000 and @juberti - as discussed previously in this thread, I'm yanking the SRTP AVP profiles from the next version of this draft.

Because people keep talking to me about wanting to use QUIC-level feedback to the sender, and even suppress similar RTCP-level feedback for efficiency's sake, I'm adding registration of QUIC/RTP/AVP, recognizing that this may not be useful in the short term, and could easily be yanked from a future version of the draft,, based on how QUIC/RTP/ encapsulation plays out in the future.

I'm working on a PR for this, and will ask for your feedback on it before committing. I will be especially in your thoughts about the new section on "Rationale on the Choice of AVP Profiles in the Context of RTP Encapsulation in QUIC".

And thank you both for your feedback so far!

suhasHere commented 2 years ago

QUIC/RTP/AVP, QUIC/RTP/AVPF are good candidates and I agree with @juberti as well as it is hop-by-hop and srtp/dtls-srtp is not adding value in this case.

Although I feel the AVPF variant will be bit tricky when considering RTCP.

The only caveat I can think is if and when there are QUIC terminators in between, the hop-by-hop (between the client and sfu) will be broken and that's where DTLS-SRTP might be useful, i think. May be its just a note in the security consideration section and nothing needs to be done here.

SpencerDawkins commented 2 years ago

I asked this question on the AVTCORE mailing list, in a thread starting here.