Subject: [rtcweb] Question about srtp_mki in DTLS/SRTP

From: Bernard Aboba <[email-masked]>
Date: Tue, 13 Jan 2015 16:48:02 -0800

A question about negotiation of the use of the SRTP MKI field in DTLS/SRTP.

RFC 5764 Section 4.1.3 has this to say about negotiation of support for the
SRTP MKI field in SRTP/SRTCP:

4.1.3 <https://tools.ietf.org/html/rfc5764#section-4.1.3>.  srtp_mki value

   The srtp_mki value MAY be used to indicate the capability and desire
   to use the SRTP Master Key Identifier (MKI) field in the SRTP and
   SRTCP packets.  The MKI field indicates to an SRTP receiver which key
   was used to protect the packet that contains that field.

Looking at draft-ietf-rtcweb-rtp-usage, draft-ietf-rtcweb-security and
draft-ietf-rtcweb-security-arch, there is no additional mention of the
SRTP MKI field.

What can be concluded about negotiation and support for the SRTP MKI
field within WebRTC implementations?

Do existing WebRTC implementations have the capability to receive or
send with the SRTP MKI field (e.g. if the peer implementation requests
it?)

Do existing WebRTC implementations indicate a desire to use the SRTP MKI field?

Does the IETF RTCWEB WG have any additional guidance to provide on
this topic beyond what is in RFC 5764 Section 4.1.3?

---

From: 🔓Dan Wing <[email-masked]>
Date: Tue, 13 Jan 2015 17:24:51 -0800

On Jan 13, 2015, at 4:48 PM, Bernard Aboba <[email-masked]> wrote:

> RFC 5764 Section 4.1.3 has this to say about negotiation of support for the SRTP MKI field in SRTP/SRTCP: 
> 
> 4.1.3.  srtp_mki value
> 
> Looking at draft-ietf-rtcweb-rtp-usage, draft-ietf-rtcweb-security and draft-ietf-rtcweb-security-arch, there is no additional mention of the SRTP MKI field.  
> 
> What can be concluded about negotiation and support for the SRTP MKI field within WebRTC implementations? 
> 
> Do existing WebRTC implementations have the capability to receive or send with the SRTP MKI field (e.g. if the peer implementation requests it?)
> 
> Does the IETF RTCWEB WG have any additional guidance to provide on this topic beyond what is in RFC 5764 Section 4.1.3?

The function of SRTP MKI overlaps with EKT (Encrypted Key Transport), and using both would significantly complicate EKT.  Thus, in EKT, we prohibit using MKI and EKT together.  EKT brings a lot of advantages to conferencing which cannot be achieved solely with MKI (no matter how MKI is signaled).  For WebRTC, I don't see SRTP MKI being used.

-d

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Jan 2015 17:31:11 -0800

On 13 January 2015 at 17:24, 🔓Dan Wing <[email-masked]> wrote:
> For WebRTC, I don't see SRTP MKI being used.

I'm not aware of anyone using it.  I too would rather prohibit its
use.  That limits two-party session length, but from a practical
perspective, that limit is going to be reached rarely, if ever without
a re-handshake.

Note that EKT isn't a perfect replacement because we should be
prohibiting the initiation of EKT from browser endpoints (well,
applications shouldn't be able to set the value used, though I guess
they could request that the browser initiate EKT).

---

From: 🔓Dan Wing <[email-masked]>
Date: Tue, 13 Jan 2015 17:38:38 -0800

> they could request that the browser initiate EKT).

Yes, something explaining how WebRTC can safely use EKT needs to be written, probably a document owned by RTCWEB.

-d

---

From: Simon Perreault <[email-masked]>
Date: Wed, 14 Jan 2015 10:08:00 -0500

> Do existing WebRTC implementations have the capability to receive or send with the SRTP MKI field (e.g. if the peer implementation requests it?)
Mine doesn't because OpenSSL doesn't support srtp_mki negotiation.

I would much prefer to use MKI because otherwise re-handshake is very
complex and brittle. I did implement re-handshake, which is uncommon.

Simon

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 14 Jan 2015 08:08:08 -0800

Simon said:

"I would much prefer to use MKI because otherwise re-handshake is very
complex and brittle. I did implement re-handshake, which is uncommon."

[BA] Can you describe the scenario for DTLS re-handshake?

---

From: Simon Perreault <[email-masked]>
Date: Wed, 14 Jan 2015 11:34:27 -0500

> [BA] Can you describe the scenario for DTLS re-handshake?

Sure. It is described in detail here:
https://tools.ietf.org/html/rfc5764#section-5.2

Basically when a re-handshake happens you have to keep old keys around for
120 seconds in case old SRTP packets are still traveling the internet and
have yet to arrive.

Without an MKI, when packets arrive you have to try to authenticate them
with the newest key, and if that doesn't work try progressively older keys.
It's a hassle: you have to store keys in chronological order and iterate.

With an MKI in the packet there's no iteration: you know exactly which key
to use. You just grab it from the key table which you index by MKI.

Simon

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Jan 2015 09:26:33 -0800

> It's a hassle: you have to store keys in chronological order and iterate.

Yes, SRTP doesn't carry the epoch and trial decryption sucks, so the
MKI is quite attractive... if you rekey.  However, as it stands, very
few implementations will permit a DTLS re-handshake.  Firefox and
Chrome actively disable renegotiation (desktop Chrome anyway, I'm not
100% on the BoringSSL-based versions, like Android).

Rekeying for very long sessions sounds attractive, but I don't see it
happening in the short term.  Actually, given expected session
durations and the likelihood of a connection breaking, I think that
the number of times when it might be necessary is vanishingly small.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 14 Jan 2015 12:43:14 -0500

> 100% on the BoringSSL-based versions, like Android).
You can handle the key transition based on the SRTP sequence numbers. Not
the greatest thing but it does work. BoringSSL versions do not support
renegotiation either.
_____________
Roman Shpount

---

From: Simon Perreault <[email-masked]>
Date: Wed, 14 Jan 2015 13:21:02 -0500

On Wed, Jan 14, 2015 at 12:43 PM, Roman Shpount <[email-masked]> wrote:

> the greatest thing but it does work.
>

Please explain.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 14 Jan 2015 13:39:48 -0500

> the number of times when it might be necessary is vanishingly small.

I don't disagree. At 50 packets per second you're good for 497 days without
a rekey. Also, didn't renegotiation just get removed from TLS 1.3 or did I
get that wrong?

Simon

---

From: Roman Shpount <[email-masked]>
Date: Wed, 14 Jan 2015 13:40:05 -0500

>> the greatest thing but it does work.
You can use the old key, until the first SRTP packet fails to verify, try
to verify the SRTP packet using new key and record sequence number for this
SSRC as the first sequence for which new key is used. For all subsequent
packets use the new SRTP key. For all previous -- repeat the above process.
This should work in the absence of MKI. At the end of the day this is
simply optimization of trying to decode using multiple keys. You do need to
maintain the list of old keys, time them out, and keep the sequence numbers
for each SSRC where you start using each key.

_____________
Roman Shpount

---

From: Simon Perreault <[email-masked]>
Date: Wed, 14 Jan 2015 13:43:38 -0500

> for each SSRC where you start using each key.

Yes, that's the optimization described in the last paragraph of
https://tools.ietf.org/html/rfc5764#section-5.2. I didn't implement it
because I don't believe it actually optimizes anything. It certainly makes
code more complex, and could actually take more time to execute because of
branch misprediction.

Simon

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Jan 2015 11:16:26 -0800

> a rekey. Also, didn't renegotiation just get removed from TLS 1.3 or did I

Renegotiation is gone, but rekeying is going to be put back in.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 14 Jan 2015 14:37:15 -0500

On Wed, Jan 14, 2015 at 2:16 PM, Martin Thomson <[email-masked]>
wrote:

> > Also, didn't renegotiation just get removed from TLS 1.3 or did I
> > get that wrong?
>

use_srtp is in ClientHello, and that's renegotiation, right? If so, can you
end up with new keys without a new MKI?

Simon

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Jan 2015 13:49:54 -0800

> end up with new keys without a new MKI?

The use_srtp extension really only allows the peers to negotiate which
SRTP cipher they want to use, it doesn't really establish the keys.
That's the role of the exporter.

In theory, you could derive new SRTP keys without doing a
renegotiation, but we don't have a defined way of doing that.

SRTP is somewhat disconnected from the whole DTLS thing.  So I think
that the idea is that it continues with the old keys until it receives
some signal.  Either an MKI bump, or the sequence number discontinuity
thing Roman suggests using.  Either way, you need some signal *in
SRTP* that the keys have changed.

And then it's down to assumptions: assume that the DTLS master secret
has changed and re-export to get new traffic keys.  Of course, you
*really* need to check that the master secret has changed or you get
into trouble.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 14 Jan 2015 17:43:27 -0500

> That's the role of the exporter.

Ok.... but I think you may have missed my point. My point is that srtp_mki,
being part of use_srtp, only gets renewed upon renegotiation. So if you
just export new keying material without renegotiating, you don't have a new
MKI for those new keys you just exported. So removing renegotiation
effectively makes srtp_mki useless. Unless I misunderstand the difference
between renegotiation and rekey...

Simon

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Jan 2015 14:51:35 -0800

On 14 January 2015 at 14:43, Simon Perreault <[email-masked]> wrote:
> being part of use_srtp, only gets renewed upon renegotiation. So if you just
> export new keying material without renegotiating, you don't have a new MKI
> for those new keys you just exported. So removing renegotiation effectively
> makes srtp_mki useless. Unless I misunderstand the difference between
> renegotiation and rekey...

OK, my bad.  Yes, the srtp_mki field in the DTLS handshake is
effectively useless without renegotiation.  If you rekey without
renegotiation, you will need a new scheme for signaling in SRTP proper
when those changes were applied (like Roman's seqno hack).