Subject: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt

From: Flemming Andreasen <[email-masked]>
Date: Fri, 5 Feb 2016 11:29:03 -0500

Greetings MMUSIC

This is to announce a 2 week WGLC on the  draft:

      https://www.ietf.org/id/draft-ietf-mmusic-dtls-sdp-06.txt

as Proposed Standard. Please review and provide any comments you may 
have on the document by Friday, February 19, 2016. Comments should be 
sent to the document authors and the MMUSIC WG list. If you review the 
document but do not have any comments, please send a note to that effect 
as well.

Thanks

-- Flemming (MMUSIC co-chair)

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 19 Feb 2016 15:35:09 +0000

I reviewed the draft and have some minor comments.

1) Section 1, the second paragraph is redundant and can be removed. It is
well stated with additional content in the paragraph that immediately
follows.

2) Section 3.1
s/following to the procedures/following the procedures

3) Section 3.2 and 3.3
OLD: "the endpoint MUST either change its DTLS role, its fingerprint value
and/or use²
NEW: "the endpoint MUST change its DTLS role, change its fingerprint
value, and/or use" 

4) Section 5.1
OLD: "e.g. regarding usage of usage specific SDP attributes etc²
NEW: ³e.g. regarding usage of specific SDP attributes²

5) Section 5.1
s/and needs/and need
s/or whether a previous/or a previous

6) Section 5.1
OLD: "Endpoints MUST NOT use the SDP 'connection' attribute [RFC4145] when
   negotiating a DTLS association.²
NEW: "Endpoints MUST NOT use the SDP 'connection' attribute [RFC4145]
within the same ³m=³ line in which they are negotiating a DTLS
association.²

7) Section 5.3
s/receives and offer/receives an offer
s/towards the the offerer/towards the offerer

8) Section 11
IANA considerations to be updated as Paul already noted.

Cheers,
Charles

On 2/5/16, 8:29 AM, "mmusic on behalf of Flemming Andreasen (fandreas)"
<[email-masked] on behalf of [email-masked]> wrote:

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Feb 2016 17:31:05 +0000

Hi Charles,

Thanks for your comments! I will implement all but 6) as suggested.

Regarding 6), it is not forbidden to use the 'connection' attribute in the m- line if it is used for something else than the DTLS connection. The subsequent paragraph gives an example of SCTP usage with DTLS.

But, I can combine the paragraphs, and modify:

"This specification does not define the usage of the SDP 'connection' attribute [ref] for negotiating a DTLS connection. However, the attribute MAY be used if the DTLS connection is used together with another protocol, e.g. SCTP or TCP, for which the usage of the attribute has been defined."

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Charles Eckel (eckelcu)<mailto:[email-masked]>
Sent: ‎19/‎02/‎2016 17:35
To: mmusic<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Flemming Andreasen (fandreas)<mailto:[email-masked]>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt

2) Section 3.1

3) Section 3.2 and 3.3

4) Section 5.1

5) Section 5.1
s/and needs/and need

6) Section 5.1

7) Section 5.3

8) Section 11

Cheers,
Charles

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 19 Feb 2016 17:48:28 +0000

Works for me. Thanks Christer.

Cheers,
Charles

From: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 19, 2016 at 6:31 PM
To: Charles Eckel <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "Flemming Andreasen (fandreas)" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt

Hi Charles,

Regards,

Christer

Sent: 19/02/2016 17:35

2) Section 3.1

3) Section 3.2 and 3.3

4) Section 5.1

5) Section 5.1
s/and needs/and need

6) Section 5.1

7) Section 5.3

8) Section 11

Cheers,
Charles

On 2/5/16, 8:29 AM, "mmusic on behalf of Flemming Andreasen (fandreas)"
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

>[email-masked]<mailto:[email-masked]>

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 21 Feb 2016 16:54:21 -0500

The WGLC has ended and Christer has already submitted an update to 
address the comments received.

We did not see a lot of review indications from the group though, so if 
you did review the draft but did not have any comments, we would 
appreciate hearing from you.

Thanks

On 2/5/16 11:29 AM, Flemming Andreasen wrote:
> document but do not have any comments, please send a note to that 
> effect as well.
>
> Thanks
>
> .

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Feb 2016 15:17:46 -0500

I went through the full draft (-08) again, not just the diffs. I found a 
few things:

* Intro:

Reading the intro I would jump to the conclusion that the primary reason 
for this draft is to define the way for explicitly signaling a new 
association. While this is important, I don't think it is *the* reason. 
Rather, IIUC, the reason is to centralize DTLS negotiation procedures 
for many protocols that require it.

* Section 3.1:

The third bullet is:

    o  The establishment of a new DTLS association is explicitly
       signaled;

ISTM that this isn't quite right. I think it should say:

    o  The desire/intent to establish of a new DTLS association is
       explicitly signaled;

* Section 4:

    A 'dtls-connection' attribute value of 'new' indicates that a new
    DTLS association MUST be established.  A 'dtls-connection' attribute
    value of 'existing' indicates that a new DTLS association MUST NOT be
    established.

The 2nd sentence above isn't entirely true. It is contradicted by 
section 5.3:

    ... or if the answerer receives
    an offer that contains an 'dtls-connection' attribute with an
    'existing' value and the answerer determines (based on the criteria
    for establishing a new DTLS association) that a new DTLS association
    is to be established, the answerer MUST insert a 'new' value in the
    associated answer.

IMO 5.3 must prevail here, because the answerer may not agree that there 
is an existing connection to reuse. So the working in section 4 should 
change. How about:

    ... A 'dtls-connection' attribute
    value of 'existing' indicates a preference to reuse an existing
    association.

* Section 5.1:

    The certificate received during the DTLS handshake MUST match the
    fingerprint received in the SDP "fingerprint" attribute.  If the
    fingerprint does not match the hashed certificate, then the endpoint
    MUST tear down the media session immediately.  ...

This talks about *the* fingerprint. But, IIUC, multiple fingerprints may 
be supplied. What is the required processing in that case?

* Section 5.3:

If the offer specified 'existing' but the answerer changes to 'new', 
should the setup attribute settings remain as they had been? (Which then 
determines which end sends the ClientHello message.)

What should be done if the offer doesn't contain a setup attribute?

* Section 9.2 (NEW TEXT)

    The far endpoint (answerer) may now establish a DTLS association with
    the offerer.  Alternately, it can indicate in its answer that the
    offerer is to initiate the TLS association.  ...

Why does this first say DTLS and then use TLS? IIUC they should both be 
DTLS.

That is all I found. I think it is almost done.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Feb 2016 09:04:05 +0000

Hi Paul,

Once again, thank you for a good review. See inline.

>I went through the full draft (-08) again, not just the diffs. I found a few things:
>
>* Intro:
>
> Reading the intro I would jump to the conclusion that the primary reason for this draft is to define the way for 
> explicitly signaling a new association. While this is important, I don't think it is *the* reason. 
> Rather, IIUC, the reason is to centralize DTLS negotiation procedures for many protocols that require it.

We tried to cover that in the first paragraph of the Introduction, but I guess some additional text could be added. E.g.:

   "[RFC5763] defines SDP Offer/Answer procedures for SRTP-DTLS.  [RFC7345]
   defines SDP Offer/Answer procedures for UDPTL-DTLS. This specification
   defines general Offer/Answer procedures for DTLS. Other specifications,
   defining specific DTLS usages, can then reference this specification, in order
   to ensure that the DTLS aspects are common among all usages. Having
   common procedures is essential when multiple usages share the same
   DTLS association [referene-to-BUNDLE]."

--------------------

>    o  The desire/intent to establish of a new DTLS association is

I'll look into that, but your suggestion seems ok.

--------------------

> The 2nd sentence above isn't entirely true. It is contradicted by section 5.3:
>
> IMO 5.3 must prevail here, because the answerer may not agree that there is an existing connection to reuse. So the working in section 4 should change. How about:
>

I'll look into that, but your suggestion seems ok.

--------------------

> This talks about *the* fingerprint. But, IIUC, multiple fingerprints may be supplied. What is the required processing in that case?

We try to clarify that in section 3.4, which says:

   "It is possible to associate multiple SDP fingerprint attribute values
   to an 'm-' line.  If any of the attribute values associated with an
   'm-' line are removed, or if any new attribute values are added, it
   is considered a fingerprint value change."

--------------------

>* Section 5.3:
>
>If the offer specified 'existing' but the answerer changes to 'new', should the setup attribute settings remain as they had been? (Which then determines which end sends the ClientHello message.)

Not sure I understand. If a new DTLS association is to be established, shouldn't it be allowed to re-negotiate the roles (read: change the value of the 'setup' attribute)?

>What should be done if the offer doesn't contain a setup attribute?

We assume the default value, which is "active" (RFC 4145).

The text says that the setup value is included "according to the procedures in [RFC4145]", but we could always include a note saying what the default value is.

--------------------

> Why does this first say DTLS and then use TLS? IIUC they should both be DTLS.

Correct.

--------------------

NEW COMMMENT:

In addition, I noticed that the document uses "DTLS connection" terminology in a few places, while the intention is to use "DTLS association" (which is also used in the RFCs we update).

The question is whether the name of the SDP attribute should still be "dtls-connection", or whether we should change it to "dtls-association". My personal preference would be to keep the "dtls-connection" name, but I can live with both.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Feb 2016 12:14:35 -0500

>     DTLS association [referene-to-BUNDLE]."

WFM

Right. But AFAIK that is the only place it is mentioned. At the least, 
most places that reference "the fingerprint" should acknowledge that 
there may be more than one.

And *someplace* needs to say what the semantics of use are when there is 
more than one. (Maybe it is defined in one of the references?) Am I 
correct in assuming that providing multiple fingerprints is for the 
convenience of the recipient, who can then pick the one that it prefers 
to verify?

> Not sure I understand. If a new DTLS association is to be established, shouldn't it be allowed to re-negotiate the roles (read: change the value of the 'setup' attribute)?

The problem is that the offerer specified "existing", and so followed 
the rules for doing that. So it had to use the last negotiated setup 
value. But the answerer has decided to switch to "new". At this point 
there are limits on what it can do - there can't be a full negotiation.

If the offer contained "active" or "passive" then the answerer is stuck 
with what was previously negotiated. If the offer contained "actpass" 
then maybe the answerer could choose either "active" or "passive" 
independent of what was previously negotiated. I think this needs to be 
explained and clarified as to what is allowed.

> The text says that the setup value is included "according to the procedures in [RFC4145]", but we could always include a note saying what the default value is.

OK. I didn't check 4145.

On one hand using dtls-connection draws parallels with 'connection', 
which might be good.

On the other hand the parallels aren't complete, so maybe changing it 
would emphasize that it *isn't* the same.

And then it is rather last in the process to be making this change.

I guess I'm neutral on this.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Feb 2016 20:26:27 +0000

Hi,

...

 --------------------

> Right. But AFAIK that is the only place it is mentioned. At the least, most places that reference "the fingerprint" 
> should acknowledge that there may be more than one.

I guess we could use "one or more SDP 'fingerprint' attributes" terminology instead of "an SDP 'fingerprint' attribute".

> And *someplace* needs to say what the semantics of use are when there is more than one. (Maybe it is defined in one 
> of the references?) Am I correct in assuming that providing multiple fingerprints is for the convenience of the
> recipient, who can then pick the one that it prefers to verify?

I don't think the semantics are defined anywhere, unless it is defined in some RTCWEB document... I remember that it was agreed at some point that multiple fingerprints were allowed, but I am not sure whether anything was written down in a specificaiton...

In my opinion, the semantics belong to RFC 4572.

--------------------

>>> should the setup attribute settings remain as they had been? (Which 
>>> then determines which end sends the ClientHello message.)
>>
>> Not sure I understand. If a new DTLS association is to be established, shouldn't it be allowed 
>> to re-negotiate the roles (read: change the value of the 'setup' attribute)?
>>
>> The problem is that the offerer specified "existing", and so followed the rules for doing that. So it had 
>> to use the last negotiated setup value. But the answerer has decided to switch to "new". At this point 
> If the offer contained "active" or "passive" then the answerer is stuck with what was previously negotiated. If the 
> offer contained "actpass" then maybe the answerer could choose either "active" or "passive" independent of what 
> was previously negotiated. I think this needs to be explained and clarified as to what is allowed.

Ok, now I understand.

The text does say that the 'setup' attribute must be set according to RFC 4572, so I think that covers what values are allowed.

But, perhaps we could add a note, saying that if the answerer is not able to able to select a 'setup' value that reflects it capabilities, it must reject the m- line. That of course also applies to the handling of the initial offer.

--------------------

NEW COMMMENT:

>> In addition, I noticed that the document uses "DTLS connection" terminology in a few places, while the 
>> intention is to use "DTLS association" (which is also used in the RFCs we update).
>>
>> The question is whether the name of the SDP attribute should still be "dtls-connection", or whether we 
>> should change it to "dtls-association". My personal preference would be to keep the "dtls-connection" name, but I can live with both.
>
> On one hand using dtls-connection draws parallels with 'connection', which might be good.

Yes - that is exactly the reason why my preference is 'dtls-connection' :)

> On the other hand the parallels aren't complete, so maybe changing it would emphasize that it *isn't* the same.

Well, 'DTLS connection' is used in some specifications...

> I guess I'm neutral on this.

So, unless someone objects, I'll keep it as it is.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Feb 2016 15:36:47 -0500

Jonathan,

Can you (as the author of RFC4572) explain the use of multiple 
fingerprints? The dtls-sdp draft talks about the possibility of multiple 
fingerprints, but I can find no explanation of the semantics of that.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Feb 2016 20:43:46 +0000

Adding Ekr, Martin and Justin, because I think they (or, at least some of them :) were behind the idea of allowing multiple fingerprints.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 24 February 2016 22:37
To: Jonathan Lennox <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt

Jonathan,

Can you (as the author of RFC4572) explain the use of multiple fingerprints? The dtls-sdp draft talks about the possibility of multiple fingerprints, but I can find no explanation of the semantics of that.

	Thanks,
	Paul

On 2/24/16 3:26 PM, Christer Holmberg wrote:

>> And *someplace* needs to say what the semantics of use are when there 
>> is more than one. (Maybe it is defined in one of the references?) Am 
>> I correct in assuming that providing multiple fingerprints is for the convenience of the recipient, who can then pick the one that it prefers to verify?
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 24 Feb 2016 15:48:05 -0500

> fingerprints, but I can find no explanation of the semantics of that.

I think the original explanation was that TLS (or DTLS) session is
terminated if none of the fingerprints matched. In other words, at least
one fingerprint MUSt match for the session to be established,

One of the use cases is when RTP and RTCP DTLS flows are using different
certificates. In this case two fingerprint attributes will be added to SDP
m= line. When separate DTLS associations are established for RTP and RTCP,
each of these association will match one of the fingerprints and fail to
match the other.

Another use case is to generate an offer that will work with remote end
points that support different certificate signature algorithms. For
instance when transitioning from SHA-1 to SHA-256 two certificates would be
created by the origination end point and fingerprints for both will be
included. When DTLS association is negotiated, it will establish which
certificate signature algorithm is supported by both parties and use the
appropriate certificate. Once again, only one of the fingerprints will
match.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Feb 2016 15:48:23 -0500

Christer,

> Hi,

That would work. But maybe this should wait for clarification on the use 
of multiple fingerprints.

> In my opinion, the semantics belong to RFC 4572.

I sent a separate reply on this, asking Jonathan to comment.

Now that we have discussed it, I agree that this is sufficient.

> But, perhaps we could add a note, saying that if the answerer is not able to able to select a 'setup' value that reflects it capabilities, it must reject the m- line. That of course also applies to…

Yes. I'm not sure if this is needed.

When setup is used with TCP/SCTP there may be cases where passive can't 
be supported, because incoming connection requests are blocked. (That 
was one of the reasons for negotiating this.) But I don't think that 
holds for DTLS if the transport has already been established. So AFAIK 
nothing should prevent either end from taking either role. So it might 
not need to be mentioned.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Feb 2016 13:12:10 -0800

> Adding Ekr, Martin and Justin, because I think they (or, at least some of them :) were behind the idea of allowing multiple fingerprints.

https://tools.ietf.org/html/draft-thomson-mmusic-fingerprint-00 is an
old take on the problem, it contains an explanation of what I think
the intent was.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Feb 2016 16:12:29 -0500

On 2/24/16 3:48 PM, Roman Shpount wrote:
> On Wed, Feb 24, 2016 at 3:36 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     fingerprints? The dtls-sdp draft talks about the possibility of
>     multiple fingerprints, but I can find no explanation of the
>     semantics of that.
>
>
> certificates. In this case two fingerprint attributes will be added to
> SDP m= line. When separate DTLS associations are established for RTP and
> RTCP, each of these association will match one of the fingerprints and
> fail to match the other.

Where is that explained?

> instance when transitioning from SHA-1 to SHA-256 two certificates would
> be created by the origination end point and fingerprints for both will
> be included. When DTLS association is negotiated, it will establish
> which certificate signature algorithm is supported by both parties and
> use the appropriate certificate. Once again, only one of the
> fingerprints will match.

But rfc4572 says:

    A certificate fingerprint MUST be computed using the same one-way
    hash function as is used in the certificate's signature algorithm.
    (This ensures that the security properties required for the
    certificate also apply for the fingerprint.  It also guarantees that
    the fingerprint will be usable by the other endpoint, so long as the
    certificate itself is.)

That seems to exclude creating fingerprints with multiple algorithms, or 
any need to do so.

Looking deeper, I find OLD TEXT (from 7345) that talks about multiple 
fingerprints, for differing cipher suites. So I guess in that case 
multiple certificates will also be presented, with a fingerprint for 
each, and it is only necessary to verify one of them.

But the NEW TEXT removes all of this, changing it to refer to *this* 
draft. But equivalent text isn't present in this draft!!!

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Wed, 24 Feb 2016 16:22:01 -0500

On Wed, Feb 24, 2016 at 4:12 PM, Paul Kyzivat <[email-masked]> wrote:

> fingerprints, for differing cipher suites. So I guess in that case multiple
> certificates will also be presented, with a fingerprint for each, and it is
> only necessary to verify one of them.
>

I was talking about using multiple fingerprints to offer multiple cipher
suites. I am not sure what draft this is present in, but this is what EKR
explained to me in on the list.

Can you send the reference to this OLD TEXT you mentioned so that it can be
added to this draft?

Thank You,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Feb 2016 16:47:10 -0500

> old take on the problem, it contains an explanation of what I think

I can't say I fully understand it, or its implications. But it does look 
like it might have been the basis of the text under discussion.

But I gather this never ended up in any active draft/rfc.

If we are going to make normative references to multiple fingerprints we 
need some place authoritative to reference for the details.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Feb 2016 16:50:55 -0500

On 2/24/16 4:22 PM, Roman Shpount wrote:
> On Wed, Feb 24, 2016 at 4:12 PM, Paul Kyzivat <[email-masked]
>     That seems to exclude creating fingerprints with multiple
>     algorithms, or any need to do so.
>
>     Looking deeper, I find OLD TEXT (from 7345) that talks about
>     multiple fingerprints, for differing cipher suites. So I guess in
>     that case multiple certificates will also be presented, with a
>     fingerprint for each, and it is only necessary to verify one of them.
>
> suites. I am not sure what draft this is present in, but this is what
> EKR explained to me in on the list.

As noted above, this text is in 7345. But the updates to 7345 that are 
present in dtls-sdp (section 9.3) *remove* that text!

> Can you send the reference to this OLD TEXT you mentioned so that it can
> be added to this draft?

Section 9.3 of dtls-sdp.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Feb 2016 21:58:27 +0000

Hi,

...

>> I was talking about using multiple fingerprints to offer multiple 
>> cipher suites. I am not sure what draft this is present in, but this 
>> is what EKR explained to me in on the list.
>
> As noted above, this text is in 7345. But the updates to 7345 that are present in dtls-sdp (section 9.3) *remove* that text!
>
>> Can you send the reference to this OLD TEXT you mentioned so that it 
>> can be added to this draft?
>
> Section 9.3 of dtls-sdp.

Maybe I'm just tired, but I don't find it, so could you please copy the part of the old text in section 9.3 that talks about multiple fingerprints?

The intention has not been to remove anything, only to move common parts from 7345 into draft-dtls-sdp.

Thanks!

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Feb 2016 14:01:54 -0800

> need some place authoritative to reference for the details.

I recommend judicious use of copy and paste.  Feel free to steal text
that I wrote.

FWIW, my reading of 4572 is that it permits multiple fingerprints: one
for each certificate that might be used.  Its failing is that a) it
doesn't allow for hash agility, and b) it's unclear, perhaps in the
extreme.

However, I see this:

   Endpoints MUST support SHA-256 for generating and verifying the
   fingerprint value associated with the DTLS association.  The use of
   SHA-256 is preferred.

Which doesn't mention that this requires an update of 4572.

And this:

   The certificate received during the DTLS handshake MUST match the
   fingerprint received in the SDP "fingerprint" attribute.

Which should say '*a* fingerprint', to allow for there being multiple.

And this:

   [...]  In addition, the offerer
   MUST insert an SDP 'setup' attribute according to the procedures in
   [RFC4145], and an SDP 'fingerprint' attribute according to the
   procedures in [RFC4572], in the offer.

Which doesn't deal with multiple certificates.

I also see:

   The
   subjectAltName is not an important component of the certificate
   verification.

Which is true but insufficient; the text can simply say that the
certificate is only a receptacle for a public key and authentication
is tied to an a=fingerprint line in the SDP.

And this:

   This offer includes, as part of the SDP payload, the fingerprint of
   the certificate that the endpoint wants to use.  The endpoint SHOULD

Which should be plural fingerprint*s*.

The pattern repeats throughout.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Feb 2016 17:46:28 -0500

> I recommend judicious use of copy and paste.  Feel free to steal text

First I think it is necessary to decide which document needs this. Then 
the copy/paste can proceed. If it belongs in the body of dtls-sdp then I 
guess it is straightforward to proceed.

If it is in one of the documents that dtls-sdp updates (5763 or 7345) 
then I guess the changes can still be tucked into sdp-dtls.

If it requires something else then it may get more messy.

> for each certificate that might be used.

It doesn't say there *can't* be multiple fingerprints. But I see nothing 
obvious that suggests that is a possibility. There is a lot of usage of 
"the fingerprint" in the text. If it is intended, then ISTM that more 
explanation is needed.

> Its failing is that a) it

Yup.

> Which doesn't mention that this requires an update of 4572.

rfc7345 has some similar (not identical) text about this. It is unclear 
to me if that overrides 4572, or supplements it.

Then dtls-sdp updates 7345, removing that text, and replacing it it with 
a reference to itself. Then again similar text is included in section 4.1.

After all those changes I don't know where we stand. But none of those 
places are clear about multiple fingerprints. And I don't know which of 
them ought to be authoritative about that subject.

I don't know what the fix is. I only know there is a problem.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Feb 2016 17:50:05 -0500

> The intention has not been to remove anything, only to move common parts from 7345 into draft-dtls-sdp.

Please see my reply to Martin.

Note that I am also getting confused now. There are two many documents 
that reference, override, and update one another. Bottom line is I can't 
find any explanation for multiple fingerprints or the hash agility that 
Martin is looking for.

I don't think I am competent to propose a fix for this.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Feb 2016 15:14:03 -0800

On 24 February 2016 at 14:50, Paul Kyzivat <[email-masked]> wrote:
> Bottom line is I can't find any explanation for multiple fingerprints or the
> hash agility that Martin is looking for.

To be clear, hash agility is a feature.  I'm OK with not having that feature.

As far as the rest of this goes, I think that dtls-sdp can address the
multiple certificates thing easily, but it appears that it would be
easier as an editorial exercise, followed by working group review,
than it would be to sort it out on the list.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Feb 2016 23:48:26 +0000

Hi Martin,

...

> Which doesn't mention that this requires an update of 4572.

I do agree that it would make sense to mandate support of the same ciphers for both TLS and DTLS (assuming that is the reason you think an 4572 update is needed), but I wonder whether such change is within the scope of this draft.  Having said that, though, I have no problem making such update in draft-dtls-sdp, if people think we should do it... :)

(The background to mandating support of SHA-256 was when we did RFC 7345. The security folks required it during the IESG review.)

------------------

> Which should say '*a* fingerprint', to allow for there being multiple.

Correct. In an earlier reply I told Paul I would modify the text to make sure it allows multiple attributes. This also applies to your subsequent comments on the same issue.

However, Paul is also looking for the semantics of using multiple fingerprints.

------------------

> I also see:
>
>   The subjectAltName is not an important component of the certificate
>   verification.
>
> Which is true but insufficient; the text can simply say that the certificate is only a receptacle for a public key and authentication is tied to an a=fingerprint line in the SDP.

Could you suggest the exact text change?

Thanks!

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Feb 2016 23:52:21 +0000

Hi Paul,

...

> Note that I am also getting confused now. There are two many documents that reference, override, and update one 
> another. Bottom line is I can't find any explanation for multiple fingerprints or the hash agility that Martin is looking for.

The important text to read is draft-dtls-sdp. The changes in the other RFCs is to remove common procedures which have been added to draft-dtls-sdp, and to reference to draft-dtls-sdp for those common procedures.

But, I still don't find any text in 7345 that talks about multiple fingerprints :) ANYWAY, there is no need to argue about that - if we have text describing the semantics of multiple fingerprints we should instead discuss where we'll put it.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Feb 2016 23:54:07 +0000

Hi,

...

> As far as the rest of this goes, I think that dtls-sdp can address the multiple certificates thing easily, but it appears that 
> it would be easier as an editorial exercise, followed by working group review, than it would be to sort it out on the list.

I will update the procedures, so that they allow usage of multiple fingerprints.

But, the SEMANTCIS of using multiple fingerprints belong in 4572, in my opinion. We can for sure update 4572 within draft-dtls-sdp, once we agree on such semantics text.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Feb 2016 20:05:01 -0800

On 24 February 2016 at 15:48, Christer Holmberg
<[email-masked]> wrote:
> the text can simply say that the certificate is only a receptacle for a public key and authentication is tied to an a=fingerprint line in the SDP.
>

See above.

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 25 Feb 2016 15:41:18 +0000

I can certainly agree that 4572 could use an update. I didn’t completely understand what I was doing when I wrote it; in particular, the idea that the certificate was just a repository for the public key wasn’t something I had completely grasped, and the hash agility was confused.

> On Feb 24, 2016, at 5:01 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 25 Feb 2016 13:57:07 -0500

There are two options possible here:

1. Make current draft-ietf-mmusic-dtls-sdp draft update 4572 and cover TLS
as well, essentially making it draft-ietf-mmusic-tls-and-dtls-sdp

2. Limit the scope of draft-ietf-mmusic-dtls-sdp to DTLS only. Completely
define how setup and fingerprint attributes are used there for DTLS only.
Let some future draft update RFC 4572.

What is the preference here given that either option will require another
major edit for draft-ietf-mmusic-dtls-sdp?

Regards,

_____________
Roman Shpount

On Thu, Feb 25, 2016 at 10:41 AM, Jonathan Lennox <[email-masked]>
wrote:

> I can certainly agree that 4572 could use an update. I didn’t completely
> understand what I was doing when I wrote it; in particular, the idea that
> the certificate was just a repository for the public key wasn’t something I
> had completely grasped, and the hash agility was confused.
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Feb 2016 18:59:09 +0000

3. Write a separate draft that updates 4572.

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 25 February 2016 20:57
To: Jonathan Lennox <[email-masked]>
Cc: Martin Thomson <[email-masked]>; mmusic <[email-masked]>; Paul Kyzivat <[email-masked]>; Christer Holmberg <[email-masked]>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt

1. Make current draft-ietf-mmusic-dtls-sdp draft update 4572 and cover TLS as well, essentially making it draft-ietf-mmusic-tls-and-dtls-sdp

2. Limit the scope of draft-ietf-mmusic-dtls-sdp to DTLS only. Completely define how setup and fingerprint attributes are used there for DTLS only. Let some future draft update RFC 4572.

What is the preference here given that either option will require another major edit for draft-ietf-mmusic-dtls-sdp?

Regards,

_____________
Roman Shpount

On Thu, Feb 25, 2016 at 10:41 AM, Jonathan Lennox <[email-masked]<mailto:[email-masked]>> wrote:
I can certainly agree that 4572 could use an update. I didn’t completely understand what I was doing when I wrote it; in particular, the idea that the certificate was just a repository for the public key wasn’t something I had completely grasped, and the hash agility was confused.

> On Feb 24, 2016, at 5:01 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
>
> On 24 February 2016 at 13:47, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Feb 2016 19:18:39 +0000

Hi,

Personally, I have no problem updating RFC 4572 within draft-ietf-mmusic-dtls-sdp, depending on how big the update would be.

The currently identified potential updates are:

1)      Define the semantics of associating multiple SDP ‘fingerprint’ attributes with an “m=” line.

2)      Update the preferred cipher suite in order to align with DTLS (SHA-1 -> SHA-256).

Regarding 1), I’d be happy if someone could commit to providing text (even if it is simply copying something from Martin’s draft). Also, is it enough to update section 5 of RFC 4572, or do we need to update some other sections too?

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 25 February 2016 20:59
To: Roman Shpount <[email-masked]>; Jonathan Lennox <[email-masked]>
Cc: mmusic <[email-masked]>; Paul Kyzivat <[email-masked]>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 25 February 2016 20:57
To: Jonathan Lennox <[email-masked]<mailto:[email-masked]>>
Cc: Martin Thomson <[email-masked]<mailto:[email-masked]>>; mmusic <[email-masked]<mailto:[email-masked]>>; Paul Kyzivat <[email-masked]<mailto:[email-masked]>>; Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt

Regards,

_____________
Roman Shpount

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 25 Feb 2016 19:23:24 +0000

On Feb 25, 2016, at 2:18 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Another potential update would be to remove (or relax) the requirement that the fingerprint use the same hash algorithm as the certificate.  This seems like a necessary corollary to 1), but is also useful on its own.

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 25 February 2016 20:59
To: Roman Shpount <[email-masked]<mailto:[email-masked]>>; Jonathan Lennox <[email-masked]<mailto:[email-masked]>>
Cc: mmusic <[email-masked]<mailto:[email-masked]>>; Paul Kyzivat <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt

Regards,

Christer

Regards,

_____________
Roman Shpount