Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer?

[Christer Holmberg <[e-mail]>]

Hi,

>>I have updated the PR. The text now allows the offerer to establish the
>>DTLS
>> association before it has received the SDP answer, but that any media
>> received before the answer shall be considered unauthenticated.
>>
>> https://github.com/cdh4u/draft-dtls-sdp/pull/31
>>
>> I intend to submit a new version of the draft soon, so please indicate
>>if
>> you don¹t agree with the text ­ together with text that you (and
>>hopefully
>> others) would agree too :)
>
>Roman is right here, this is going too far.  As ekr points out, we
>over-corrected by insisting that the handshake not proceed without the
>answer, but doesn't mean that we should let the handshake complete
>without knowing to whom we are completing the handshake with.
>
>There is a case for taking the data you receive and holding it until
>you get an answer; it would be OK to allow that, though it would need
>some careful writing.
>
>However, I believe that the reason we've been asked to do this is in
>aid of actually playing out media from a completely unauthenticated
>source.  That's the point at which this goes pear-shaped.  The whole
>point of this is to provide integrity, and that doesn't happen if an
>attacker gets to provide the first few bits of a stream.
>
>I realize that this makes Cullen's use case harder, but several
>alternative solutions have been offered.
>
>My preference is to forbid handshake completion until the anchors by
>which the handshake is assessed (a=fingerprint, a=tls-id) are
>available.

If I understand correctly, you seem to suggest that we allow the handshake
to ³proceed² (see 1st paragraph of your reply), but not to ³complete². If
so, which endpoint is responsible to make sure that it doesn¹t ³complete²?

>Second in preference to that is to allow received data to be saved,
>but not used.  In no circumstance should we allow data to be *sent*.

I assume that also includes e.g., SCTP messages, i.e., in case of a WebRTC
Data Channel it wouldn¹t be allowed to establish the SCTP association.


Regards,

Christer







>It's very hard to guarantee that an error that is detected on the peer
>will actually result in the connection terminating in a reasonable
>period of time.  The current draft is vague on this point.
>
>p.s., Tim's comment about media vs. data needs to be addressed.