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

On Tue, May 16, 2017 at 9:54 AM, Eric Rescorla <[email protected]> wrote:

>
>
> On Mon, May 15, 2017 at 11:43 PM, Christer Holmberg <
> [email protected]> wrote:
>
>> The pull request based on the WGLC comments from Roman S and Martin T,
>> suggests text saying that if an offerer receives ClientHello it must not
>> send ServerHello until it has received the answer (that carries the
>> fingerprint associated with the DTLS association).
>>
>
> I may have missed their comments, but I don't understand why you would
> make that
> rule. In neither TLS 1.2 or 1.3 are you able to evaluate the fingerprint
> at this
> point anyway, because you don't have the cert.
>
> It's one thing not to determine that the handshake is complete until you
> receive
> the answer, but that's different from not sending the SH. That seems
> silly. [0]
>
>
First of all, draft-thomson-mmusic-sdp-uks puts tls-id from the answer in
ClientHello. This tls-id can be used to identify that received ClientHello
is related to the current signaling exchange and refuse other ClientHello
messages.

Second, not sending ServerAnswer until signaling answer is received,
prevents unverified media and removes significant number of execution paths
that would need to be defined both in the dtls-id specification and then
tested during development and interop of compliant solutions. I do not want
to spend time defining this unless it is absolutely necessary.

As a small historic reference, all that previous versions of specifications
said is that ClientHello can be received by the offering party before the
answer is received. It did not specify how such ClientHello should be
processed. Webrtc group in W3C asked how unverified media should be
handled. We have determined that this should not occur with WebRTC end
points, but this does point out that handling of unverified media is indeed
undefined. I think dtls-id is the right place to specify this and the
simplest thing I can see is to prohibit it.

Regards,
_____________
Roman Shpount

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