Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-09

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Feb 2016 07:29:47 +0000

Hi,

Based on the comments given by Paul and Martin, and the mail discussion regarding updating RFC 4572, I've submitted a new version of draft-dtls-sdp-09.

The O/A section now allows usage of multiple 'fingerprint' attributes.

The draft does NOT update RFC 4572. My parsing of the outcome was that any updates will be done in a separate draft.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Feb 2016 11:05:36 -0500

This is better. A couple of things about this one:

In section 5.1:

    The certificate received during the DTLS handshake MUST match a
    fingerprint received in an SDP "fingerprint" attribute.  If a
    fingerprint does not match the hashed certificate, then the endpoint
    MUST tear down the media session immediately.  Note that it is
    permissible to wait until the other side's fingerprint has been
    received before establishing the connection; however, this may have
    undesirable latency effects.

IIUC, when there are multiple fingerprints the intent is that there will 
be multiple certificates, each matching one of the fingerprints. And 
that the point of this is that the recipient be able to deal with at 
least one of them, not that the recipient must verify all of them.

(Do I have that right?)

If so, I don't think the text above is consistent with that. I think it 
should probably say:

    One of the certificates received during the DTLS handshake MUST
    match one of the fingerprints received in an SDP "fingerprint"
    attribute.  If not, then the endpoint MUST tear down the media
    session immediately.  Note that it is permissible to wait until
    the other side's fingerprints have been received before establishing
    the connection; however, this may have undesirable latency effects.

If the above is true, then it is possible that adding/changing a 
fingerprint might not require establishing a new DTLS association. If 
the association had been established based on a fingerprint that 
remains, then it doesn't matter what happens to the other fingerprints.

I don't have a clear understanding of if/how that might change the text. 
And I don't see a reason why anybody would do that.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Feb 2016 19:33:18 +0000

Hi Paul,

> IIUC, when there are multiple fingerprints the intent is that there will be multiple certificates, each 
> matching one of the fingerprints. And that the point of this is that the recipient be able to deal with 
> at least one of them, not that the recipient must verify all of them.
>
> (Do I have that right?)
>
> If so, I don't think the text above is consistent with that. I think it should probably say:
>
> If the above is true, then it is possible that adding/changing a fingerprint might not require establishing a 
> new DTLS association. If the association had been established based on a fingerprint that remains, then it 
> doesn't matter what happens to the other fingerprints.

MAYBE (there are others that know this better than me) there are cases where a new DTLS association would not be required, but I think we should have consistent rules.

And, as far as I know, it is quite unlikely that there will be any fingerprint changes within a session to begin with, so I don't think we are going to end up in a situation with lots of DTLS associations being re-established even if there may not be a need for it.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 29 Feb 2016 16:52:38 -0500

On Mon, Feb 29, 2016 at 2:33 PM, Christer Holmberg <
[email-masked]> wrote:

> fingerprint might not require establishing a
> MAYBE (there are others that know this better than me) there are cases
> where a new DTLS association would not be required, but I think we should
> have consistent rules.
>
> And, as far as I know, it is quite unlikely that there will be any
> fingerprint changes within a session to begin with, so I don't think we are
> going to end up in a situation with lots of DTLS associations being
> re-established even if there may not be a need for it.
>

Even though it is technically possible to keep the connection if the
fingerprint of the currently used certificate did not change, I think it is
more important to have consistent rules in which end points will have no
ambiguity that new DTLS association must be re-established. I do not see
any use cases when one of the fingerprints changed while others were kept
the same.

Forcing new DTLS association when any fingerprint changes also allows the
signaling agent to easily examine the SDP and validate that if any
fingerprints changed, dtls-association attribute is set to new. It would be
much harder to verify what dtls-association value should be in SDP if
partial fingerprint changes were allowed on the connection, since signaling
agent might not have means to determine which fingerprint was currently
used to verify the media connection.

Things also would become really confusing in case when different
certificates are used for RTP and RTCP. End point might want to change only
of the certificates and keep the other certificate the same. This end point
will change only one fingerprint in the SDP. What dtls-connection value
should be there? Is it existing connection or the new one? It would be much
simpler to require that both connections were simply re-established.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Feb 2016 17:16:49 -0500

On 2/29/16 4:52 PM, Roman Shpount wrote:
> On Mon, Feb 29, 2016 at 2:33 PM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>      > new DTLS association. If the association had been established
>     based on a fingerprint that remains, then it
>     MAYBE (there are others that know this better than me) there are
>     cases where a new DTLS association would not be required, but I
>     think we should have consistent rules.
>
>     fingerprint changes within a session to begin with, so I don't think
>     we are going to end up in a situation with lots of DTLS associations
>     being re-established even if there may not be a need for it.
>
>
> fingerprint of the currently used certificate did not change, I think it
> is more important to have consistent rules in which end points will have
> no ambiguity that new DTLS association must be re-established. I do not
> see any use cases when one of the fingerprints changed while others were
> kept the same.
>
> Forcing new DTLS association when any fingerprint changes also allows
> the signaling agent to easily examine the SDP and validate that if any
> fingerprints changed, dtls-association attribute is set to new. It would
> be much harder to verify what dtls-association value should be in SDP if
> partial fingerprint changes were allowed on the connection, since
> signaling agent might not have means to determine which fingerprint was
> currently used to verify the media connection.
>
> certificates are used for RTP and RTCP. End point might want to change
> only of the certificates and keep the other certificate the same. This
> end point will change only one fingerprint in the SDP. What
> dtls-connection value should be there? Is it existing connection or the
> new one? It would be much simpler to require that both connections were
> simply re-established.

I am ok with deciding that the rule should be if any fingerprint changes 
then a new association is required.  Not because it is technically 
necessary, but simply because it makes the rules simpler and more 
comprehensible, and because the likelihood of this causing an inordinate 
extra cost is low.

But we should not say or imply that the recipient is obligated to check 
that each of the fingerprints match a cert. (We can require this of the 
sender.) It should be sufficient for the receiver to pick the 
fingerprint(s) it is going to use and check them.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Mon, 29 Feb 2016 17:41:52 -0500

> fingerprint(s) it is going to use and check them.
For recipient it should be sufficient to check dtls-association attribute.
Sender must set dtls-association to new if it changed any of the
fingerprints.
_____________
Roman Shpount