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

[Martin Thomson <[e-mail]>]

On 22 May 2017 at 18:24, Christer Holmberg
<[e-mail]> wrote:
> 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.

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