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

On Tue, May 16, 2017 at 7:24 AM, Roman Shpount <[email protected]> wrote:

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

Not following why that is necessary at this stage. You can reject the
handshake
when it completes.


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

I'm not sure what you're talking about in terms of "ServerAnswer". That's
not a TLS
concept AFAIK.

-Ekr



> 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