Subject: Re: [AVTCORE] QUIC-SRTP (was Re: Running multiple quic sessions over the same address/port pair)

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 1 Mar 2022 08:34:59 -0600

I agree with Bernard, but especially about this part -

On Tue, Mar 1, 2022 at 12:24 AM Bernard Aboba <[email-masked]>
wrote:

> On Feb 28, 2022, at 18:54, Martin Thomson <[email-masked]> wrote:
> >
> > Has anyone seriously considered using QUIC-SRTP?  You could use the
> QUIC session for data and other such things, but some or all of the media
> could run alongside.  I'm not following the RTP over QUIC work very
> closely, but it seems like an interim solution - which would be much more
> like SCTP and its use with bundle - might be a low effort option.
>
> [BA] The discussion on RTP/QUIC is relatively young at this point. So it’s
> a good time to ask “why?” questions.
>

YES. Specifically, if I understand Martin's train of thought, it's also a
good time to think about "what do we need to do?".

The discussion on this mailing list about SRTP over QUIC and the resulting
double encryption is a great example of that - of course I can register the
protos for that with IANA, but is there a compelling reason for me to do
that? The closest I've come to a compelling reason was so that (at least
some) RFC 7667 middleboxes will know whether to use SRTP to forward RTP
packets to non-RTP-QUIC endpoints, but then (paraphrasing Justin's question
to me) why not just send that middlebox a message saying "forward this
using SRTP", or even (paraphrasing myself) just write a BCP that says "if
you receive an RTP message over QUIC, forward it using SRTP", so no
signaling at all.

We can do a lot of things. What do we need to do?

Best,

Spencer