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

[Roman Shpount <[e-mail]>]

On Fri, Jun 9, 2017 at 9:32 AM, Cullen Jennings <[e-mail]> wrote:

> I'd really really appreciate if you could give me a hint of it you agree
> with my original points I asked about or which ones you disagree with and
> why. The three points I am interested in are:
>
> For devices that want to minimize delay in setting up media and avoid
> media clipping, doing the TLS handshake as soon as possible is good design
> but in some cases this means the system does  the handshake before the
> identity of the fingerprint is known.
>

Doing TLS handshake as soon as possible is a good design. Doing answer
identity and integrity validation and validating certificate fingerprints
as soon as possible is a better design. I understand that doing answer and
fingerprint validation is not always possible when interfacing with legacy
SIP devices, but there is no reason to design new solutions which process
media before the answer. For instance WebRTC has no reason to support
unverified media. Because of this, I think that anything that produces
unverified media is a bad design which has no reason to exist apart for
legacy interop. Specifics on how to design session description identity and
integrity validation are clearly out of scope for this draft.

All of this being said, what I am proposing for the sake of moving this
draft forward does not contradict any of your points. Once again, what I am
proposing is:

1. Remove any recommendation regarding handling DTLS association before the
answer (leave it up to implementation)
2. Put a note that accepting DTLS association before the answer can result
in unverified media and if this media is played back to the end user, end
user SHOULD be notified that media is coming from an unverified source.
3. Add clarification that DTLS associations established before the answer
MUST be torn down when no more answers are expected and that fingerprints
in any of the received answers match the negotiated certificate (Right now
it is specified that DTLS association MUST be torn down if it does not
match the answer. This is wrong if forking is used and multiple answers are
received).


Draft does not advise that DTLS association should be established before
the answer is received (I think this is wrong), but it also does not advise
that it should not (you think it is wrong). This way implementation decides
what's best for it.

Does it contradict anything that you want to accomplish?
If it does, what needs to be changed?

Regards,
_____________
Roman Shpount