- From: Matthew Kaufman <matthew@matthew.at>
- Date: Wed, 23 Mar 2011 17:29:49 -0700
On 3/23/2011 5:22 PM, Harald Alvestrand wrote: > On 03/24/11 01:13, Matthew Kaufman wrote: >> On 3/23/2011 3:17 PM, Harald Alvestrand wrote: >>> Is there really an advantage to not using SRTP and reusing the RTP >>> format for the data messages? >> >> I'd go one further... why not DTLS-SRTP for the media and DTLS with >> some other header shim for the data messages? > RFC 5764? That's the one. And in particular RFC 5763... but with the fingerprint exposed to Javascript (for arbitrary transport of the authentication) vs. mandating SDP transport. Also in 5763 see 5.1.2 for how to demultiplex STUN connectivity checks, SRTP, DTLS messages and potentially additional application data packet types. > > I think that's a discussion we need to have in the IETF RTCWEB > WG-in-formation, though. Will you be in the BOF on Tuesday? > Agree that this is more an IETF than WHATWG problem, and I will indeed be headed to Prague this weekend. > The biggest counterargument I could see coming is that it's going to > be signficantly harder to make it interoperate with existing SRTP > deployments that negotiate keys over the signalling channel. There is an argument to be had that *also* supporting SDES-style keying (via forced keying through a Javascript API) would be useful in some cases, both for legacy interop and for forcing same-key for many-party mixing scenarios, but not having something with end-to-end key agreement (and preferably, perfect forward secrecy thereof) built in would be a major setback for user privacy. Matthew Kaufman
Received on Wednesday, 23 March 2011 17:29:49 UTC