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

On Feb 8, 2006, at 12:54 PM, Hadriel Kaplan wrote:

> 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.

I think it's tricky to use MKIs in this way.

>
>>> 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.

I see your point.  We chose to treat keys differently than codecs for  
the reasons I mentioned in my previous note.

>
>> 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?

I think it's fine to pass both keys to mitigate the problem of  
sending media before the answer is received.

> 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.

I agree.

> But we'll get
> there with the early-media draft, or just by 1xx responses w/SDP,  
> so problem
> solved.  :)

We can only hope ;-)

cheers, Mark
>
> -hadriel

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