Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt

[Matt Fredrickson <[e-mail]>]

On Tue, Oct 29, 2013 at 10:23 AM, Paul Kyzivat <[e-mail]>wrote:

> On 10/27/13 5:45 AM, Randell Jesup wrote:
>
>> On 10/26/2013 6:30 PM, Paul Kyzivat wrote:
>>
>
>  My proposal has three elements, which together can guarantee that
>>>> there are no stream id allocation conflicts between peers:
>>>>     1. The browser and application select stream ids based on initial
>>>> SDP offerer/answerer role rather than DTLS role (e.g., initial
>>>> offerer uses even ids, initial answerer uses odd ids). With this
>>>> rule, the offering application knows its role immediately without
>>>> waiting for the DTLS or SDP handshake to occur.
>>>>
>>>
>>> A similar issue has come up in the discussion of partial
>>> offers/answers. (Regarding how to assign a=mid values.) And a similar
>>> solution was proposed.
>>>
>>> It was then rejected on the basis that sometimes both "ends" think
>>> they are offerers or answerers. This comes about as a result of
>>> signaling-only B2BUAs that play games with O/A on two legs.
>>>
>>
>> Exactly why we went with DTLS roles.
>>
>
> I'm not sure this eliminates the problem.
>
> Is it not possible for an intermediary on the signaling path to insert
> itself in the media path, manipulating the SDP such that the two ends both
> establish the DTLS with the intermediary?


Correct me if I'm wrong, but I thought that the SDP itself was supposed to
be signed and able to be validated (perhaps using the identity mechanism),
to explicitly catch nefarious man in the middle type scenarios such as this.

Matthew Fredrickson