RE: [MMUSIC] Re: ADs - Re: Status ofdraft-ietf-mmusic-sdescriptions-12.txt?

Comments inline...

> -----Original Message-----
> From: Mark Baugher [mailto:mbaugher@cisco.com]
> Sent: Wednesday, February 08, 2006 2:15 PM
> To: Hadriel Kaplan
> Cc: mmusic@ietf.org; 'Flemming Andreasen'; 'Dan Wing'; 'Jon Peterson';
> 'Allison Mankin'; 'Brian E Carpenter'; 'Colin Perkins'; 'Joerg Ott'
> Subject: Re: [MMUSIC] Re: ADs - Re: Status ofdraft-ietf-mmusic-
> sdescriptions-12.txt?
> What you say is correct and thanks for the clarification.  My point
> is that it is not simply a matter of handing a bidirectional master
> key or a second, unidirectional master key to the receiver for
> sending its media so long as multiple offers are possible.  The real
> problem to the problem of early commencement of media is the presence
> of multiple offers in the SDP message not the way a key is sent.

But doesn't that problem get solved with unique MKIs?  In the way
draft-wing-mmusic-sdes-early-media-00.txt handles it, or at least that's how
I read it.

> > the sdes offerer sent the keys for transmitting media, instead of
> > the ones
> > for receive-side as it does with everything else in SDP.
> 
> I'm not sure what you mean by "as it does with everything else in
> SDP."  There are recvonly, sendonly and sendrecv attributes in SDP
> for specifying direction semantics.  In the earliest versions of SDP

Yup, sorry meant it more in the sense that when you make the offer you're
saying you can immediately receive any of the offered codecs at the offered
ports. (ie, with respect to early media)  A nit really.

> So why not have the SDP offerer offer two keys? The quality of the
> encryption is greatly affected by the randomness of the key.  When
> creating keys, it is best to have each side add some randomness in
> the key derivation as is commonly done in pairwise key establishment
> protocols.  This is not possible for groups and sdesc needs to
> support groups.  Supplying an encryption key to the receiver is risky
> because in some protocols, such as SIP, the supplied key is handed to
> a group of receivers when forking occurs, thus raising the
> probability of SSRC collision.  The next best thing IMHO is to at
> least allow a sender to ensure the quality of a key for *its* data by
> supplying the decryption key for its data.  I'm not religious about
> this point.  If supplying the encryption key (rather than or in
> addition to the decryption key) to the receiver solved the problem
> described above, I'd personally support that.  But it doesn't.

I was waiting for that, so I could say wouldn't that also apply to
draft-wing-mmusic-sdes-early-media-00.txt, since the draft allows the
offerer to tell the answerer both keys?  But thinking about this more, I
guess having both ways lets the market choose, which is preferred.

As to the overlapping SSRC problem with an offered key, I think the risk of
that happening, and happening for long enough to be cracked (in practical
terms), etc., is outweighed by the usefulness of early media.  But we'll get
there with the early-media draft, or just by 1xx responses w/SDP, so problem
solved.  :)

-hadriel

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic