Subject: [AVT] FW: I-D Action:draft-lennox-avt-srtp-encrypted-extension-headers-01.txt

From: Jonathan Lennox <[email-masked]>
Date: Mon, 8 Mar 2010 17:19:35 -0500

I'd like to call the AVT group's attention to this Internet-Draft I've just submitted, for encrypting RTP header extensions when SRTP is used.  This was motivated by the audio-levels work, due to concern that sending per-packet audio levels in the clear might expose too much information to third-party observers.

I submitted version -00 of this draft before the Hiroshima meeting, but I was not present at that meeting and it was not presented.  This version has only minor revisions from the previous version.

Comments are welcome.

-- 
Jonathan Lennox
Vidyo, Inc
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 08, 2010 4:00 PM
To: [email-masked]
Subject: I-D Action:draft-lennox-avt-srtp-encrypted-extension-headers-01.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP)
	Author(s)       : J. Lennox
	Filename        : draft-lennox-avt-srtp-encrypted-extension-headers-01.txt
	Pages           : 8
	Date            : 2010-03-08

The Secure Real-Time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-Time Transport Protocol (RTP) packets.  However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality.  This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lennox-avt-srtp-encrypted-extension-headers-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.
W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1sZW5ub3gtYXZ0LXNydHAtZW5jcnlwdGVkLWV4dGVuc2lvbi1oZWFkZXJzLTAxLnR4
dA0K

---

From: "Wyss, Felix" <[email-masked]>
Date: Wed, 10 Mar 2010 22:00:59 -0500

What is the motivation for the encryption mask?  Are there really sufficiently compelling cases where the content of some header extension elements must be accessible to intermediate devices not privy to the keys?  I cannot imagine that reduced computation is the motivation as the overhead of managing the masks will likely outweigh the savings in cryptographic operations.  Furthermore, considering the small size of header extension elements, it is to be expected that the whole cipher stream will have to be generated anyway as there won't be sufficiently large runs of zeroes in the masks. 

Regards,
--Felix Wyss
Interactive Intelligence, Inc.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jonathan Lennox
> Sent: Monday, March 08, 2010 17:20
> To: [email-masked]
> Subject: [AVT] FW: I-D Action:draft-lennox-avt-srtp-encrypted-extension-
> headers-01.txt
> 
> I'd like to call the AVT group's attention to this Internet-Draft I've
> just submitted, for encrypting RTP header extensions when SRTP is used.
> This was motivated by the audio-levels work, due to concern that sending
> per-packet audio levels in the clear might expose too much information to
> third-party observers.
> 
> I submitted version -00 of this draft before the Hiroshima meeting, but I
> was not present at that meeting and it was not presented.  This version
> has only minor revisions from the previous version.
> 
> Comments are welcome.
> 
> --
> Jonathan Lennox
> Vidyo, Inc
> [email-masked]
> 
> 
> The Secure Real-Time Transport Protocol (SRTP) provides authentication,
> but not encryption, of the headers of Real-Time Transport Protocol (RTP)
> packets.  However, RTP header extensions may carry sensitive information
> for which participants in multimedia sessions want confidentiality.  This
> document provides a mechanism, extending the mechanisms of SRTP, to
> selectively encrypt RTP header extensions in SRTP.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 11 Mar 2010 11:25:36 -0500

The motivation for the encryption mask was indeed allow senders to expose some extension headers to intermediate nodes while protecting others.  Specifically, I vaguely recall that there were some intended use-cases where a third party monitored toffset (RFC 5450) header extensions, so that it could make accurate jitter measurements for RTP streams (such as video) whose RTP timestamps differ from transmission time.

Re-using the RFC 5285 format directly also makes it somewhat easier to negotiate a fall-back to standard 5285 with SRTP, without needing to use something like SDP cap-neg.

That said, the extension mask does indeed somewhat complicate the mechanism, though not greatly, I don't think.  I agree that it'd be very unlikely that it would produce any computational savings, especially as header extensions probably wouldn't use more than one or two blocks of keystream in any case.

Does anyone know if there are any current or planned uses of RTP header extensions being watched by third-party monitors?

-- 
Jonathan Lennox
Vidyo, Inc
[email-masked]

> From: Wyss, Felix [mailto:[email-masked]]
> Sent: Wednesday, March 10, 2010 10:01 PM
> To: Jonathan Lennox; [email-masked]
> Subject: RE: [AVT] FW: I-D Action:draft-lennox-avt-srtp-encrypted-
> extension-headers-01.txt
> 
> What is the motivation for the encryption mask?  Are there really
> sufficiently compelling cases where the content of some header
> extension elements must be accessible to intermediate devices not privy
> to the keys?  I cannot imagine that reduced computation is the
> motivation as the overhead of managing the masks will likely outweigh
> the savings in cryptographic operations.  Furthermore, considering the
> small size of header extension elements, it is to be expected that the
> whole cipher stream will have to be generated anyway as there won't be
> sufficiently large runs of zeroes in the masks.
> 
> Regards,
> --Felix Wyss
> > Subject: I-D Action:draft-lennox-avt-srtp-encrypted-extension-
> headers-
> > 01.txt
> >
> > 	Filename        : draft-lennox-avt-srtp-encrypted-extension-
> headers-
> > 01.txt
> > 	Pages           : 8
> > 	Date            : 2010-03-08
> >