Re: draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer?
Martin Thomson <[email protected]>
| Newsgroups | gmane.ietf.mmusic |
|---|---|
| Message-ID | <CABkgnnXzzKMWrPaGq6mho=Dmq7Hjbi_G4Ng1O6LBCTL-1Pt-hA@mail.gmail.com> |
On 22 May 2017 at 18:24, Christer Holmberg <[email protected]> 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. _______________________________________________ mmusic mailing list [email protected] https://www.ietf.org/mailman/listinfo/mmusic