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

From: Paul Kyzivat <[email-masked]>
Date: Tue, 1 Mar 2016 15:01:22 -0500

On 2/29/16 5:41 PM, Roman Shpount wrote:
> On Mon, Feb 29, 2016 at 5:16 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     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.
>
>
> 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.

Two things are mixed up here.

If dtls-association says requests a new association, then recipient 
should follow that.

If dtls-association says 'existing', or is absent, and there is an 
existing association, then the recipient should check for a change in 
fingerprints. If there is a change, then do a new association anyway.

When there is to be a new association, then certificates will need to be 
checked. IMO the fingerprint recipient then decides what certificate to 
check, and must check the fingerprint on that one. It does not need to 
verify that the other fingerprints are valid.

(I've almost lost track, but I think this was regarding the following 
NEW TEXT:)

    ... The answerer is then able to verify that the offerer's
    certificate used for authentication in the DTLS handshake can be
    associated to the certificate fingerprint contained in the offer in
    the SDP.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Tue, 1 Mar 2016 15:55:13 -0500

n Tue, Mar 1, 2016 at 3:01 PM, Paul Kyzivat <[email-masked]> wrote:

> If dtls-association says requests a new association, then recipient should
> follow that.
>

This is correct.

> fingerprints. If there is a change, then do a new association anyway.

If dtls-association says 'existing' and if any fingerprints changed or
added, this is a malformed SDP and such SDP should be refused with an error.

If dtls-association is absent and if any fingerprints changed or added,
then new DTLS association MUST be set up.

> verify that the other fingerprints are valid.

When there is a new association, new DTLS handshake occurs. During this
handshake, capabilities and then certificates are exchanged. Certificate
received from the remote party is checked against the list of fingerprints.
If a fingerprint matching the certificate is found, then connection is
accepted. If no matching fingerprint is found, connection MUST be torn down.

If this does not get through in the language of the specification, it
should be updated to reflect this.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 1 Mar 2016 16:32:01 -0500

On 3/1/16 3:55 PM, Roman Shpount wrote:

> received from the remote party is checked against the list of
> fingerprints. If a fingerprint matching the certificate is found, then
> connection is accepted. If no matching fingerprint is found, connection
> MUST be torn down.

What is unclear (to me) is how to deal with multiple fingerprints. And, 
IIUC, there can also be multiple certificates.

As it used to be, the crypto used on the fingerprint had to match that 
on the certificate. So if you could handle the certificate you could 
handle the fingerprint. I gather that there is now a request to break 
that linkage. So the fingerprint might use a different crypto than the 
cert if signs.

So, am I to choose all the certs I can decode and try to verify them 
with all the fingerprint I can?

What are the criteria for success? One fingerprint verifying one cert?

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Tue, 1 Mar 2016 17:30:44 -0500

On Tue, Mar 1, 2016 at 4:32 PM, Paul Kyzivat <[email-masked]> wrote:

> As it used to be, the crypto used on the fingerprint had to match that on
> the certificate. So if you could handle the certificate you could handle
> the fingerprint. I gather that there is now a request to break that
> linkage. So the fingerprint might use a different crypto than the cert if
> signs.
>
> So, am I to choose all the certs I can decode and try to verify them with
> all the fingerprint I can?
>

There is going to be one certificate used for a given DTLS association in
each direction. In case of RTP and RTCP there are two associations, so two
certificates can be used. Security certificate is selected based on the
security settings and configuration of DTLS stack. Fingerprint plays no
role at this point. Certificate is nothing more here then the public key
and does not even have to be signed. Once DTLS connection is established,
signaling stack can request the negotiated certificate from this
connection. Signaling stack can then calculate a signature of this
certificate using any available hash function and compare it with the
fingerprint value. If multiple fingerprints are present in SDP with the
same or different hash functions, these fingerprints should be checked one
at a time and if any of them match, DTLS association will be established.
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Wed, 2 Mar 2016 12:59:03 +1100

On 1 March 2016 at 03:05, Paul Kyzivat <[email-masked]> wrote:
>    One of the certificates received during the DTLS handshake MUST

Note: While there are multiple certificates in a DTLS handshake, ONLY
the end-entity certificate should be checked.  Checking against other
certificates would be a serious bug and a huge security vulnerability.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Mar 2016 09:50:50 -0500

> certificates would be a serious bug and a huge security vulnerability.

It would be good to say that somewhere.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Mar 2016 16:25:29 +0000

Hi,

> It would be good to say that somewhere.

Should that be said in the 4572 update? Or, is it DTLS-specific?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Wed, 2 Mar 2016 11:26:48 -0500

> Should that be said in the 4572 update? Or, is it DTLS-specific?
This should be in 4572 update. This is not DTLS specific.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Mar 2016 16:43:04 +0000

So, do we still need some changes in draft-dtls-sdp?

Perhaps we should completely remove section 3.4 (“Multiple SDP fingerprint attributes”), and cover it in the 4572 update?

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 02 March 2016 18:27
To: Christer Holmberg <[email-masked]>
Cc: Paul Kyzivat <[email-masked]>; Martin Thomson <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-09

On Wed, Mar 2, 2016 at 11:25 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Mar 2016 11:56:19 -0500

On 3/2/16 11:43 AM, Christer Holmberg wrote:
> Perhaps we should completely remove section 3.4 (“Multiple SDP
> fingerprint attributes”), and cover it in the 4572 update?

Every place in the document that mentions "fingerprint" needs to be 
adjusted so it *allows* multiple fingerprints and makes sense if there 
are more than one. (You got some but not all of them.)

Hopefully anything that deals with the semantics of having multiple 
fingerprints can be delegated to 4572bis. That includes what it means if 
a fingerprint is added, removed, changed.

	Thanks,
	Paul

> Regards,
>
> Christer
>
> *From:*Roman Shpount [mailto:[email-masked]]
> *Sent:* 02 March 2016 18:27
> *To:* Christer Holmberg <[email-masked]>
> *Cc:* Paul Kyzivat <[email-masked]>; Martin Thomson
> <[email-masked]>; [email-masked]; [email-masked]
> *Subject:* Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-09
>
> On Wed, Mar 2, 2016 at 11:25 AM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hi,
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Mar 2016 16:59:58 +0000

Hi,

> Every place in the document that mentions "fingerprint" needs to be adjusted so it *allows* multiple fingerprints and makes sense if there are more than one. (You got some but not all of them.)

That change I have done, and it will be in the next version of the document.

> Hopefully anything that deals with the semantics of having multiple fingerprints can be delegated to 4572bis. That includes what it means if a fingerprint is added, removed, changed.

So, you're ok with removing section 3.4 from draft-dtls-sdp?

Note that currently draft-4572-update is currently not intended as a 4572bis.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Mar 2016 12:53:30 -0500

> So, you're ok with removing section 3.4 from draft-dtls-sdp?

Well, as long as "fingerprint value change" is used elsewhere in the 
document it needs to be defined *somewhere*. What 3.4 currently says is 
part of what bothers me, because it only makes sense if you make certain 
assumptions about the semantics of multiple fingerprints.

If it is defined in draft-4572-update then that can be referenced.

> Note that currently draft-4572-update is currently not intended as a 4572bis.

OK, fine.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Mar 2016 21:50:35 +0000

Hi,

>>> adjusted so it *allows* multiple fingerprints and makes sense if 
>>> there are more than one. (You got some but not all of them.)
>>
> Well, as long as "fingerprint value change" is used elsewhere in the document it needs to be 
> defined *somewhere*. What 3.4 currently says is part of what bothers me, because it only 
> makes sense if you make certain assumptions about the semantics of multiple fingerprints.
>

If we do it in draft-4572-update, then we only need to talk about "if the fingerprint changes" and  "inserting one or more fingerprint attributes" in draft-dtls-sdp, without going into the semantics.

I did a pre-10 version of the draft, and pushed it to Github:

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

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 3 Mar 2016 13:24:30 -0500

> https://github.com/cdh4u/draft-dtls-sdp

OK, that seems to do it, as long as the 4572 update sufficiently 
explains multiple fingerprints.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Mar 2016 19:34:49 +0000

Hi,

>>> document it needs to be defined *somewhere*. What 3.4 currently says 
>>> is part of what bothers me, because it only makes sense if you make certain assumptions about the semantics of multiple fingerprints.
>>>
> OK, that seems to do it, as long as the 4572 update sufficiently explains multiple fingerprints.

Ok, so I'll submit the -10 version, and I think we can finalize the WGLC. Then we can focus on the 4572 updates.

Regards,

Christer