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

Hi,

I have updated the PR. I hope it addresses the opinions of everyone:

  *   It removes any text regarding handling of DTLS associations before the answer.
  *   It adds a note saying any data received is to be considered coming from an unverified source, but that the processing of the data is outside the scope of the document
  *   It adds text to the SIP considerations, saying that the offerer should wait for all SDP answers until it declares a possible fingerprint mismatch.

https://github.com/cdh4u/draft-dtls-sdp/pull/31

Note that this PR does not address the actpass issue – any changes associated with that issue will be in a separate PR.

Regards,

Christer


From: Roman Shpount <[email protected]<mailto:[email protected]>>
Date: Friday 9 June 2017 at 17:18
To: Cullen Jennings <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Christer Holmberg <[email protected]<mailto:[email protected]>>
Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer?

On Fri, Jun 9, 2017 at 9:32 AM, Cullen Jennings <[email protected]<mailto:[email protected]>> 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

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