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

Eric Rescorla <[email protected]>
Newsgroups gmane.ietf.mmusic
Message-ID <CABcZeBN+91+kf8j599CpdiHu62QoOu4Xbkb5xhEEwSQp_LGxFw@mail.gmail.com>
On Mon, May 15, 2017 at 11:43 PM, Christer Holmberg <
[email protected]> wrote:

> Hi,
>
> 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]

-Ekr

[0] I want to preemptively acknowledge that in most full-ICE cases, you
won't
be able to send the SH at this point anyway, but that's a distinct question.



> It has been claimed that we DO need to allow the offerer to establish the
> DTLS association BEFORE it has received the answer, in order to support
> certain early media use-cases. Until the offerer has received the answer,
> such media would be considered un-authenticated. Others do not want to
> allow
> it, due to security concerns.
>
> We need to find a solution to this, so any input is welcome.
>
> The pull request: https://github.com/cdh4u/draft-dtls-sdp/pull/31/files
>
> Regards,
>
> Christer
>
>
> _______________________________________________
> mmusic mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.