Re: [secdir] review of draft-ietf-mmusic-connectivity-precon-06

[Sam Hartman <[e-mail]>]

>>>>> "Stephen" == Stephen Kent <[e-mail]> writes:
    Stephen> I find this text to be too vague to be useful. It ought
    Stephen> to cite specific mechanisms in RFCs, at least as
    Stephen> examples, preferably as recommendations. The lack of
    Stephen> specific, cited mechanisms makes this section almost
    Stephen> vacuous. I suggest that the authors revise the text here
    Stephen> to cite appropriate mechanisms.


Arje there any?  Last time I looked at ICE, it didn't have integrity
mechanisms.  Also, let's say that you added an integrity mechanism to
ICE.  How would it help against attacks that prevented media streams
from  being established?

You could defend against attacks that caused media streams to appear
to be established.  For example in the DTLS SRTP case, if you wait for
the DTLS negotiation to conclude, and if you exchanged a fingerprint
in SDP, you have fairly high confidence that you did in fact establish
the media stream.  I don't know how that interacts with everything
else going on in this draft.

One question I'd ask is how important are these attacks?  The first
category in particular--DOS attacks that prevent media streams from
appearing to establish--seems quite difficult to defend against.
Perhaps documenting it as a residual threat would be appropriate.

How much detail we go into to the second class of attack seems to
depend on how important of a threat it is.  If it is relatively
unimportant, perhaps it is sufficient to point out that integrity at
the media layer bound to an integrity protected exchange at the SDP
layer could be sufficient to defeat the attack.  I agree with Steve
that specific citations to such mechanisms should be included.
However if the attack is more important, then perhaps we need to
develop this into specific recommendations for common media stream
classes.