Re: starting DTLS handshake before the answer is received (dtls-sdp draft)

On Tue, May 2, 2017 at 7:41 PM, Bernard Aboba <[email protected]>
wrote:

> Roman Shpount said:
>
> "We also are planning to update the dtls-sdp draft which will prohibit to
> start DTLS handshake until the answer is received."
>
> [BA] The logic here is that in WebRTC an incoming DTLS packet cannot be
> responded to until "consent" is provided, which requires an ICE request and
> response, which needs the remote ICE ufrag/password, which is in the
> answer.
>
> While I can understand explaining this in the dratf,  a prohibition seems
> redundant, because it already follows from other requirements (such as
> consent and full ICE).  It's a bit like passing a law prohibiting objects
> in earth's gravity from "falling up" - gravity just doesn't work that way,
> so no need for a law.
>
> Also, there can be situations with ICE lite, or with ORTC where ICE O/A
> could be separated from DTLS O/A), so consent could exist prior to receipt
> of the DTLS answer, where the original logic wouldn't hold.
>

This is exactly the reason we are adding this restriction. In cases of
ICE-lite or symmetric UDP, it is possible for DTLS handshake to complete
before the answer is received. This brings up the question of handling
unverified media. This also does not work well with
https://datatracker.ietf.org/doc/html/draft-thomson-mmusic-sdp-uks. It can
cause end point to go through an handshake with potential attacker which
did not place the call, which creates an interesting possibility for DOS
attack where end point can be sprayed with ClientHello messages which will
cause handshake, but will not be associated with the actual call.

Our assumption was, since DTLS handshake cannot continue in most common
cases (full ICE and "proper" UDP where remote IP is not known until answer
is received), in order to make protocol negotiation more consistent we
should prohibit DTLS handshake before the answer is received in less common
cases such as ICE-lite and "symmetric" UDP.

Regards,
_____________
Roman Shpount

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic