Subject: [MMUSIC] Thoughts on draft-ietf-mmusic-dtls-sdp-10 semantics

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 Mar 2016 15:05:37 -0800

I’ve been going over draft-ietf-mmusic-dtls-sdp-10 and would like to
suggest some changes.

Here are my starting assumptions:

   -

   We do want the ability to do an ICE restart without a DTLS reconnect.
   -

   It’s not safe to do a DTLS reconnect without an ICE restart (and new
   transport parameters) because you would need to demux the connections.
   -

   Although RFC 5763 says that ICE restart implies a DTLS reconnect, that’s
   not something people actually do.
   -

   There are cases where people want to do a DTLS reconnect without
   changing fingerprints.
   -

   It needs to be safe to repeatedly apply the same description (e.g.,
   setLocalDescription() idempotently) in WebRTC.

Accordingly, I think we can get away with a something simpler:

   -

   Remove the requirement in RFC 5763 to DTLS reconnect on ICE restart.
   -

   A DTLS reconnect is required if *either*
   -

      The fingerprint changes
      -

      A (TBD, see below) indicator indicator is in the SDP
      -

   Require that if a DTLS reconnect is done for any reason you also do an
   ICE restart and it’s an error to have either of the two conditions above
   without also changing the ICE credentials.

I believe this meets all the actual use cases while discarding the legacy
use cases that are in protocol documents but not actually implemented.

Assuming you are comfortable with the above, I think the indicator we want
is some sort of “connection-id” parameter, either as a standalone value or
as a value which is unique in association with the fingerprint. This seems
cleaner than having a “new” versus “reuse” token. The semantics would be
that if you see a new identifier that means you need to form a new
association but that multiple replays of the same identifier mean that you
reuse the same association (i.e., do not DTLS reconnect).

This resolves the idempotency concern that present with the existing
proposal, and also makes backwards compatibility simpler; a change in
either a=fingerprint or a=dtls-connection-id will trigger a new DTLS
connection.

What do people think of this?

-Ekr

---

From: Ted Hardie <[email-masked]>
Date: Thu, 3 Mar 2016 15:21:39 -0800

Howdy,

On Thu, Mar 3, 2016 at 3:05 PM, Eric Rescorla <[email-masked]> wrote:

>    Although RFC 5763 says that ICE restart implies a DTLS reconnect,
>    that’s not something people actually do.
>    -
>
Can you unpack what these cases are?  I'm a little worried with the
interaction with ICE, especially in the convergence case described in 6.7.1
of RFC 5763.  That already gives a case where the IP address associated
with a DTLS handshake can shift; in a reconnect, is this supported?

>    A DTLS reconnect is required if *either*
If it is not changing on reconnect, what causes it to change?  Someone
explicitly calling SetRemoteFingerprint?

> What do people think of this?

Off-list because I don't want to rock a boat that's moving, but I don't
think this message motivated the change that well.

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

---

From: Ted Hardie <[email-masked]>
Date: Thu, 3 Mar 2016 15:22:35 -0800

My apologies; that was meant to go to Eric, and not the list; obviously I
am shy of caffeine.  I will remedy that while I experience shame.

Ted

On Thu, Mar 3, 2016 at 3:21 PM, Ted Hardie <[email-masked]> wrote:

>>    Require that if a DTLS reconnect is done for any reason you also do
>>    an ICE restart and it’s an error to have either of the two conditions above
>> Assuming you are comfortable with the above, I think the indicator we
>> want is some sort of “connection-id” parameter, either as a standalone
>> value or as a value which is unique in association with the fingerprint.
>> This seems cleaner than having a “new” versus “reuse” token. The semantics
>> would be that if you see a new identifier that means you need to form a new

---

From: Roman Shpount <[email-masked]>
Date: Thu, 3 Mar 2016 18:23:08 -0500

>    setLocalDescription() idempotently) in WebRTC.
It is actually unclear if RFC 5763 DTLS is reconnected on ICE restart. We
heard arguments both ways. In draft-ietf-mmusic-dtls-sdp we defined the
dtls-connection overwrites transport changes, so even in cases of ICE
restart or transport address changes, if dtls-connection=exisitng, new DTLS
association is not being setup. This should address your concerns about
DTLS session surviving the ICE restart.

The draft requires new transport if new DTLS association is established. We
can add language regarding ICE restart and allocating a complete new set of
candidates (i.e. end point should not be allowed to reuse any of the
existing candidates for the new connection).

The dtls-connection=new overwrites fingerprints being the same and forces
the new connection. This addresses the case when fingerprint stays the same
but new connection is required.

Applying the same description repeatedly is an important additional use
case.

> either a=fingerprint or a=dtls-connection-id will trigger a new DTLS

I have actually proposed this very thing (dtls-association-id instead of
dtls-connection), but people on the list found this to be too complex. This
has an additional benefit of handling some of the 3pcc use cases when in
response to empty INVITE it is unknown if generated offer will be used in
the same session or in the new one. dtls-association-id resolves this
nicely, but we settled for a simpler requirement to always respond with
a=dtls-connection=new in response to empty INVITE.

The question is does group feels strongly about changes to
(dtls-association-id from dtls-connection at this late stage, since this
will require a major rewrite.
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 Mar 2016 15:38:13 -0800

> with a DTLS handshake can shift; in a reconnect, is this supported?

What I heard suggested was that there were cases of, for instance, data
centers
with multiple machines with the same key but different network addresses.

> explicitly calling SetRemoteFingerprint?

I don't believe you can do this with WebRTC but you can do it obviously
with a SIP endpoint.

 -Ekr

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 3 Mar 2016 19:12:17 -0500

On 3/3/16 6:23 PM, Roman Shpount wrote:

>     Assuming you are comfortable with the above, I think the indicator
>     we want is some sort of “connection-id” parameter, either as a
>     standalone value or as a value which is unique in association with
>     the fingerprint. This seems cleaner than having a “new” versus
>     “reuse” token. The semantics would be that if you see a new
>     identifier that means you need to form a new association but that
>     multiple replays of the same identifier mean that you reuse the same
>     association (i.e., do not DTLS reconnect).
>
>
>     proposal, and also makes backwards compatibility simpler; a change
>     in either a=fingerprint or a=dtls-connection-id will trigger a new
>     DTLS connection.
>
>
> dtls-connection), but people on the list found this to be too complex.
> This has an additional benefit of handling some of the 3pcc use cases
> when in response to empty INVITE it is unknown if generated offer will
> be used in the same session or in the new one. dtls-association-id
> resolves this nicely, but we settled for a simpler requirement to always
> respond with a=dtls-connection=new in response to empty INVITE.
>

I had discomfort with connection=new/existing back when it first came up 
with TCP, exactly because it isn't idempotent. I don't recall why I lost 
that battle.

But now that is water over the dam. So I think it takes a stronger 
argument for why to adopt a different pattern now for something so 
similar. If the SDP implementation already has to deal with this for 
a=connection, then why is it a problem to also do so for dtls-connection?

	Thanks,
	Paul

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 Mar 2016 16:31:38 -0800

On Thu, Mar 3, 2016 at 4:12 PM, Paul Kyzivat <[email-masked]> wrote:

> argument for why to adopt a different pattern now for something so similar.
> If the SDP implementation already has to deal with this for a=connection,
> then why is it a problem to also do so for dtls-connection?
>

How many people actually get a=connection right?

-Ekr

---

From: Justin Uberti <[email-masked]>
Date: Thu, 3 Mar 2016 16:35:39 -0800

> then why is it a problem to also do so for dtls-connection?

I don't agree that the ship has sailed on this. If we unearth a compelling
reason (idempotency), we shouldn't be bound by decisions to a different
attribute made 10+ years ago.

Besides idempotency, the connection/instance id approach has the additional
benefit of simpler logic for old remote endpoints - if either the
fingerprint or id changes, make a new DTLS connection.

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 6 Mar 2016 17:41:08 -0500

On 3/3/16 7:31 PM, Eric Rescorla wrote:
>
>
> On Thu, Mar 3, 2016 at 4:12 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I had discomfort with connection=new/existing back when it first
>     came up with TCP, exactly because it isn't idempotent. I don't
>     recall why I lost that battle.
>

I don't know. But it should be pretty obvious when they get it wrong. 
And they have had a long time to get the bugs worked out of their code.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 6 Mar 2016 17:45:46 -0500

On 3/3/16 7:35 PM, Justin Uberti wrote:
> I don't agree that the ship has sailed on this.

I agree. (Their is a lot of *water* over the dam, but the ship hasn't 
gone over the dam yet.:-) I just said the bar was higher than normal.

> If we unearth a
> compelling reason (idempotency), we shouldn't be bound by decisions to a
> different attribute made 10+ years ago.
>
> Besides idempotency, the connection/instance id approach has the
> additional benefit of simpler logic for old remote endpoints - if either
> the fingerprint or id changes, make a new DTLS connection.

The tradeoff is that it becomes a *new* mechanism. More opportunities 
for people to misunderstand and get it wrong. More opportunities for us 
to write the description unclearly to help with that.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Mar 2016 08:09:05 +0000

So, would anyone object to the principle of going forward with an ID approach?

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 7. maaliskuuta 2016 0:46
To: Justin Uberti
Cc: [email-masked]
Subject: Re: [MMUSIC] Thoughts on draft-ietf-mmusic-dtls-sdp-10 semantics

> I don't agree that the ship has sailed on this.

I agree. (Their is a lot of *water* over the dam, but the ship hasn't gone over the dam yet.:-) I just said the bar was higher than normal.

> If we unearth a
> compelling reason (idempotency), we shouldn't be bound by decisions to 
> a different attribute made 10+ years ago.
>
> additional benefit of simpler logic for old remote endpoints - if 
> either the fingerprint or id changes, make a new DTLS connection.

The tradeoff is that it becomes a *new* mechanism. More opportunities for people to misunderstand and get it wrong. More opportunities for us to write the description unclearly to help with that.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 7 Mar 2016 11:05:06 -0500

> So, would anyone object to the principle of going forward with an ID approach?

I am ok with this, as long as it is done well.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Mon, 7 Mar 2016 11:24:08 -0500

> I am ok with this, as long as it is done well.
We will try our best. I am trying to model the language on ICE ufrag.

Any preferences on the attribute name? So far I can think of dtls-id,
dtls-association-id, or dtls-connection-id

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Mar 2016 16:26:57 +0000

I suggest dtls-association-id. In my opinion there is no longer the same need to be aligned with the name of the connection attribute.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Roman Shpount<mailto:[email-masked]>
Sent: ‎07/‎03/‎2016 18:24
To: Paul Kyzivat<mailto:[email-masked]>
Cc: Christer Holmberg<mailto:[email-masked]>; Justin Uberti<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] Thoughts on draft-ietf-mmusic-dtls-sdp-10 semantics

On Mon, Mar 7, 2016 at 11:05 AM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
On 3/7/16 3:09 AM, Christer Holmberg wrote:
So, would anyone object to the principle of going forward with an ID approach?

Any preferences on the attribute name? So far I can think of dtls-id, dtls-association-id, or dtls-connection-id

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 7 Mar 2016 12:21:52 -0500

On 3/7/16 12:12 PM, Roman Shpount wrote:
> On Mon, Mar 7, 2016 at 11:52 AM, Paul Kyzivat <[email-masked]
>     On 3/7/16 11:26 AM, Christer Holmberg wrote:
>
>         I suggest dtls-association-id. In my opinion there is no longer
>         the same
>         need to be aligned with the name of the connection attribute.
>
>
>     This seems plausible. But I want to reserve judgement until the
>     detailed semantics of the attribute are worked out:
>
> I wanted to model this attribute on ICE ufrag
>
>     - is it numeric, or a token?
>
>
> I was thinking something like this:
> dtls-association-id-attr = "dtls-association-id" ":" dtls-association-id
>
> dtls-association-id = 4*256dtls-association-id-char
>
> dtls-association-id-char = ALPHA / DIGIT / "+" / "/"

Why this in particular? Is it your intent to reuse values that were 
generated for another purpose? Or to reuse code that is also used for 
another purpose?

>     - any rules for how the value chosen?
>
>
> The dtls-association-id attributes MUST be chosen randomly when new DTLS
> association is requested.  The dtls-association-id attribute MUST
> contain at least 24 bits of randomness.  This means that
> the dtls-association-id  attribute will be at least 4 characters
> long since the grammar for this attribute allows for 6 bits of
> randomness per character.  The attribute MAY be longer than 4
> characters, respectively, of course, up to 256 characters.  The upper
> limit allows for buffer sizing in implementations.  Its large upper
> limit allows for increased amounts of randomness to be added over time.

What is the reason for using random values, rather than some well 
defined sequence of values? (Where the sequence might start with a 
random value, or perhaps every sequence would start with 0.)

	Thanks,
	Paul

>     - is it tied to an actual property of the association,
>         or is it just an arbitrary extra piece of state?
>
>
> It is not tied to the association and it is an arbitrary piece of state.
> DTLS protocol can be extended in the future to use dtls-association-id
> to demux multiple DTLS associations over the same transport but this is
> out of scope for now.
>
>     - any rules for how the *next* value is chosen when
>         a new (replacement) association is being proposed?
>
>
> New values is generated randomly.
>
>     - when (if ever) can an id be reused?
>
>
> The dtls-association-id should be reused while end point want to
> maintain the same DTLS association. If either end point changes the
> dtls-association-id value, this will indicate that new DTLS association
> MUST be established.
>
>     It is *possible* (though not likely) that the details may suggest a
>     particular name that is more meaningful than "id".
>
>
> Regards,
> _____________
> Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 7 Mar 2016 11:52:34 -0500

On 3/7/16 11:26 AM, Christer Holmberg wrote:
> I suggest dtls-association-id. In my opinion there is no longer the same

This seems plausible. But I want to reserve judgement until the detailed 
semantics of the attribute are worked out:

	Thanks,
	Paul

> ------------------------------------------------------------------------
> From: Roman Shpount <mailto:[email-masked]>
> To: Paul Kyzivat <mailto:[email-masked]>
> Cc: Christer Holmberg <mailto:[email-masked]>; Justin
> Uberti <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 7 Mar 2016 12:12:47 -0500

The dtls-association-id attributes MUST be chosen randomly when new DTLS
association is requested.  The dtls-association-id attribute MUST contain
at least 24 bits of randomness.  This means that the dtls-association-id
attribute will be at least 4 characters long since the grammar for this
attribute allows for 6 bits of randomness per character.  The attribute MAY
be longer than 4 characters, respectively, of course, up to
256 characters.  The upper limit allows for buffer sizing
in implementations.  Its large upper limit allows for increased amounts of
randomness to be added over time.

It is not tied to the association and it is an arbitrary piece of state.
DTLS protocol can be extended in the future to use dtls-association-id to
demux multiple DTLS associations over the same transport but this is out of
scope for now.

> - when (if ever) can an id be reused?

The dtls-association-id should be reused while end point want to maintain
the same DTLS association. If either end point changes the
dtls-association-id value, this will indicate that new DTLS association
MUST be established.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 7 Mar 2016 13:26:06 -0500

> generated for another purpose? Or to reuse code that is also used for

This is reusing the definition (and generation code) from ice-ufrag
attribute (https://tools.ietf.org/html/rfc5245#section-15.4).

> What is the reason for using random values, rather than some well defined
> sequence of values? (Where the sequence might start with a random value, or
> perhaps every sequence would start with 0.)
>

We are dealing with multiple end points which can be reconnected in more or
less random order. Each end point needs to detect when it is talking to a
new end point or to a new DTLS association. This is why I picked a random
value. Once again, if this works for ICE, should work for DTLS just as well.

Let me know if you have a better idea for ID generation.

Regards,
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Mon, 7 Mar 2016 18:15:58 -0800

Keep in mind that this id value isn't actually sent anywhere. So it's not
like the ICE ufrag that needs a certain amount of entropy. It can just as
easily be a monotonically increasing number.

IOW, a string with a 1-byte minimum seems right.

On Mon, Mar 7, 2016 at 10:26 AM, Roman Shpount <[email-masked]> wrote:

> We are dealing with multiple end points which can be reconnected in more
> or less random order. Each end point needs to detect when it is talking to
> a new end point or to a new DTLS association. This is why I picked a random

---

From: Roman Shpount <[email-masked]>
Date: Mon, 7 Mar 2016 23:24:31 -0500

We need to make sure dtls-association-id works in cases of 3pcc where a new
session can be connected to an existing session or two existing sessions
can be connected with each other. In all of those cases new DTLS
association must be established. The case of merging two existing sessions
especially worry me if we chose monotonically increasing IDs. Imagine two
sessions, each hitting IVR for an announcement, and then being connecting
directly with each other. If monotonically increasing from zero ID is used,
both sessions will have dtls-association-id=1, but clearly a new session
would need to be established.

I think in general monotonically increasing IDs have a high chance of
collision when unrelated end points are used. Randomly assigned IDs are
safer in this regard.

Another option is to state that dtls-association-id should be unique for a
given security certificate fingerprint. So if new certificate is created
for each DTLS association, then dtls-association-id can stay at value 0 or
be omitted. If certificate is reused a unique value should be used for each
new DTLS association created with this certificate. This uniqueness can be
achieved by using a counter associated with each self signed certificate or
using sufficiently large random or pseudo random (server id + time stamp +
per server counter would be an example of the pseudo random) value
associated with pre-provisioned permanent certificates.

Does anybody else have any suggestions or concerns about
dtls-association-id generation scheme?
______________
Roman Shpount

On Mon, Mar 7, 2016 at 9:15 PM, Justin Uberti <[email-masked]> wrote:

>>> defined sequence of values? (Where the sequence might start with a random
>>> value, or perhaps every sequence would start with 0.)
>>>
>>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 8 Mar 2016 07:54:09 +0000

Hi,

There is no need to track the “order” of DTLS associations, so I think we should use random value. I am not sure we need “+” and “-“. Would a numeric value be enough? The number of DTLS associations between the connected endpoints is going to be very small, so we shouldn’t over-engineer it.

Regarding the id being unique for a given fingerprint, keep in mind that we now allow multiple fingerprints.

Regards,

Christer

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 8 March 2016 at 06:24
To: Justin Uberti <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Christer Holmberg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] Thoughts on draft-ietf-mmusic-dtls-sdp-10 semantics

We need to make sure dtls-association-id works in cases of 3pcc where a new session can be connected to an existing session or two existing sessions can be connected with each other. In all of those cases new DTLS association must be established. The case of merging two existing sessions especially worry me if we chose monotonically increasing IDs. Imagine two sessions, each hitting IVR for an announcement, and then being connecting directly with each other. If monotonically increasing from zero ID is used, both sessions will have dtls-association-id=1, but clearly a new session would need to be established.

I think in general monotonically increasing IDs have a high chance of collision when unrelated end points are used. Randomly assigned IDs are safer in this regard.

Another option is to state that dtls-association-id should be unique for a given security certificate fingerprint. So if new certificate is created for each DTLS association, then dtls-association-id can stay at value 0 or be omitted. If certificate is reused a unique value should be used for each new DTLS association created with this certificate. This uniqueness can be achieved by using a counter associated with each self signed certificate or using sufficiently large random or pseudo random (server id + time stamp + per server counter would be an example of the pseudo random) value associated with pre-provisioned permanent certificates.

Does anybody else have any suggestions or concerns about dtls-association-id generation scheme?
______________
Roman Shpount

On Mon, Mar 7, 2016 at 9:15 PM, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:
Keep in mind that this id value isn't actually sent anywhere. So it's not like the ICE ufrag that needs a certain amount of entropy. It can just as easily be a monotonically increasing number.

On Mon, Mar 7, 2016 at 10:26 AM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Mar 7, 2016 at 12:21 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
On 3/7/16 12:12 PM, Roman Shpount wrote:
On Mon, Mar 7, 2016 at 11:52 AM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

Why this in particular? Is it your intent to reuse values that were generated for another purpose? Or to reuse code that is also used for another purpose?

This is reusing the definition (and generation code) from ice-ufrag attribute (https://tools.ietf.org/html/rfc5245#section-15.4).

What is the reason for using random values, rather than some well defined sequence of values? (Where the sequence might start with a random value, or perhaps every sequence would start with 0.)

We are dealing with multiple end points which can be reconnected in more or less random order. Each end point needs to detect when it is talking to a new end point or to a new DTLS association. This is why I picked a random value. Once again, if this works for ICE, should work for DTLS just as well.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 8 Mar 2016 19:59:51 -0500

I would make the dtls-association-id value random alphanumeric to keep it
shorter.

I would also make dtls-association-id optional if any of the fingerprints
is for a newly generated self-signed certificate which will not be reused
for any other DTLS association.

Regards,

_____________
Roman Shpount

On Tue, Mar 8, 2016 at 2:54 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> There is no need to track the “order” of DTLS associations, so I think we
> should use random value. I am not sure we need “+” and “-“. Would a numeric
> value be enough? The number of DTLS associations between the connected
> endpoints is going to be very small, so we shouldn’t over-engineer it.
>
> From: Roman Shpount <[email-masked]>
> To: Justin Uberti <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Christer Holmberg <
> [email-masked]>, "[email-masked]" <[email-masked]>
> We need to make sure dtls-association-id works in cases of 3pcc where a
> new session can be connected to an existing session or two existing
> sessions can be connected with each other. In all of those cases new DTLS

---

From: Justin Uberti <[email-masked]>
Date: Tue, 8 Mar 2016 20:35:02 -0800

I think the id should be alphanumeric, but how it is assigned can be left
to the application.

On Tue, Mar 8, 2016 at 4:59 PM, Roman Shpount <[email-masked]> wrote:

>> Another option is to state that dtls-association-id should be unique for
>> a given security certificate fingerprint. So if new certificate is created
>>> Keep in mind that this id value isn't actually sent anywhere. So it's
>>> not like the ICE ufrag that needs a certain amount of entropy. It can just
>>> as easily be a monotonically increasing number.
>>>
>>>> We are dealing with multiple end points which can be reconnected in
>>>> more or less random order. Each end point needs to detect when it is
>>>> talking to a new end point or to a new DTLS association. This is why I
>>>> picked a random value. Once again, if this works for ICE, should work for
>>>> DTLS just as well.
>>>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Mar 2016 06:46:38 +0000

So, alphanumeric it is :)

From: Justin Uberti [mailto:[email-masked]]
Sent: 09 March 2016 06:35
To: Roman Shpount <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] Thoughts on draft-ietf-mmusic-dtls-sdp-10 semantics

I think the id should be alphanumeric, but how it is assigned can be left to the application.

On Tue, Mar 8, 2016 at 4:59 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
I would make the dtls-association-id value random alphanumeric to keep it shorter.

I would also make dtls-association-id optional if any of the fingerprints is for a newly generated self-signed certificate which will not be reused for any other DTLS association.

Regards,

_____________
Roman Shpount

On Tue, Mar 8, 2016 at 2:54 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

Regards,
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Thu, 10 Mar 2016 17:55:20 -0800

With no minimum length (well, minimum of 1).

On Tue, Mar 8, 2016 at 10:46 PM, Christer Holmberg <
[email-masked]> wrote:

> *From:* Justin Uberti [mailto:[email-masked]]
> *Sent:* 09 March 2016 06:35
> *To:* Roman Shpount <[email-masked]>
> *Cc:* Christer Holmberg <[email-masked]>; Paul Kyzivat <
> [email-masked]>; [email-masked]
>
> *Subject:* Re: [MMUSIC] Thoughts on draft-ietf-mmusic-dtls-sdp-10
> semantics
>
>
>
> *From: *Roman Shpount <[email-masked]>
> *Date: *Tuesday 8 March 2016 at 06:24
> *To: *Justin Uberti <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Christer Holmberg <
> *Subject: *Re: [MMUSIC] Thoughts on draft-ietf-mmusic-dtls-sdp-10
> semantics
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Mar 2016 21:22:48 -0500

> With no minimum length (well, minimum of 1).

How random can a value with a length of 1 be?

	Thanks,
	Paul

> On Tue, Mar 8, 2016 at 10:46 PM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     So, alphanumeric it is :)____
>
>     __ __
>
>     *From:*Justin Uberti [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *To:* Roman Shpount <[email-masked] <mailto:[email-masked]>>
>     *Cc:* Christer Holmberg <[email-masked]
>     <mailto:[email-masked]>>; Paul Kyzivat
>     <[email-masked] <mailto:[email-masked]>>;
>     [email-masked] <mailto:[email-masked]>
>
>
>     semantics____
>     __ __
>     I think the id should be alphanumeric, but how it is assigned can be
>     left to the application.____
>
>     __ __
>
>     __ __
>
>     On Tue, Mar 8, 2016 at 4:59 PM, Roman Shpount <[email-masked]
>     <mailto:[email-masked]>> wrote:____
>
>         I would make the dtls-association-id value random alphanumeric
>         to keep it shorter.____
>
>         __ __
>
>         I would also make dtls-association-id optional if any of the
>         fingerprints is for a newly generated self-signed certificate
>         which will not be reused for any other DTLS association.____
>
>         __ __
>
>         Regards,____
>
>
>         ____
>
>         _____________
>         Roman Shpount____
>
>         __ __
>
>         On Tue, Mar 8, 2016 at 2:54 AM, Christer Holmberg
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:____
>
>             Hi,____
>
>             __ __
>
>             There is no need to track the “order” of DTLS associations,
>             so I think we should use random value. I am not sure we need
>             “+” and “-“. Would a numeric value be enough? The number of
>             DTLS associations between the connected endpoints is going
>             to be very small, so we shouldn’t over-engineer it.____
>
>             __ __
>
>             Regarding the id being unique for a given fingerprint, keep
>             in mind that we now allow multiple fingerprints.____
>
>             __ __
>
>             Regards,____
>
>             __ __
>
>             Christer____
>
>             __ __
>
>             *From: *Roman Shpount <[email-masked]
>             <mailto:[email-masked]>>
>             *To: *Justin Uberti <[email-masked]
>             <mailto:[email-masked]>>
>             *Cc: *"[email-masked] <mailto:[email-masked]>"
>             <[email-masked] <mailto:[email-masked]>>,
>             Christer Holmberg <[email-masked]
>             <mailto:[email-masked]>>, "[email-masked]
>             <mailto:[email-masked]>" <[email-masked]
>             <mailto:[email-masked]>>
>             *Subject: *Re: [MMUSIC] Thoughts on
>             draft-ietf-mmusic-dtls-sdp-10 semantics____
>
>             __ __
>
>             We need to make sure dtls-association-id works in cases of
>             3pcc where a new session can be connected to an existing
>             session or two existing sessions can be connected with each
>             other. In all of those cases new DTLS association must be
>             established. The case of merging two existing sessions
>             especially worry me if we chose monotonically increasing
>             IDs. Imagine two sessions, each hitting IVR for an
>             announcement, and then being connecting directly with each
>             other. If monotonically increasing from zero ID is used,
>             both sessions will have dtls-association-id=1, but clearly a
>             new session would need to be established. ____
>
>             __ __
>
>             I think in general monotonically increasing IDs have a high
>             chance of collision when unrelated end points are used.
>             Randomly assigned IDs are safer in this regard. ____
>
>             __ __
>
>             Another option is to state that dtls-association-id should
>             be unique for a given security certificate fingerprint. So
>             if new certificate is created for each DTLS association,
>             then dtls-association-id can stay at value 0 or be omitted.
>             If certificate is reused a unique value should be used for
>             each new DTLS association created with this certificate.
>             This uniqueness can be achieved by using a counter
>             associated with each self signed certificate or using
>             sufficiently large random or pseudo random (server id + time
>             stamp + per server counter would be an example of the pseudo
>             random) value associated with pre-provisioned permanent
>             certificates.____
>
>             __ __
>
>             dtls-association-id generation scheme?____
>
>             ______________ ____
>
>             Roman Shpount____
>
>             __ __
>
>             On Mon, Mar 7, 2016 at 9:15 PM, Justin Uberti
>             <[email-masked] <mailto:[email-masked]>> wrote:____
>
>                 Keep in mind that this id value isn't actually sent
>                 anywhere. So it's not like the ICE ufrag that needs a
>                 certain amount of entropy. It can just as easily be a
>                 monotonically increasing number. ____
>
>                 __ __
>
>                 IOW, a string with a 1-byte minimum seems right.____
>
>                 __ __
>
>                 On Mon, Mar 7, 2016 at 10:26 AM, Roman Shpount
>                 <[email-masked] <mailto:[email-masked]>> wrote:____
>
>                     __ __
>
>                     On Mon, Mar 7, 2016 at 12:21 PM, Paul Kyzivat
>                     <[email-masked]
>                     <mailto:[email-masked]>> wrote:____
>
>                         On 3/7/16 12:12 PM, Roman Shpount wrote:____
>
>                             <mailto:[email-masked]>
>                             dtls-association-id-attr =
>                             "dtls-association-id" ":" dtls-association-id
>
>                             dtls-association-id =
>                             dtls-association-id-char = ALPHA / DIGIT /
>                             "+" / "/"____
>
>
>                         Why this in particular? Is it your intent to
>                         reuse values that were generated for another
>                         purpose? Or to reuse code that is also used for
>                         another purpose?____
>
>                     __ __
>
>                     This is reusing the definition (and generation code)
>                     from ice-ufrag attribute
>                     (https://tools.ietf.org/html/rfc5245#section-15.4). ____
>
>                     __ __
>
>                             limit allows for increased amounts of
>                             randomness to be added over time.____
>
>
>                         What is the reason for using random values,
>                         rather than some well defined sequence of
>                         values? (Where the sequence might start with a
>                         random value, or perhaps every sequence would
>                         start with 0.)____
>
>                     __ __
>
>                     We are dealing with multiple end points which can be
>                     reconnected in more or less random order. Each end
>                     point needs to detect when it is talking to a new
>                     end point or to a new DTLS association. This is why
>                     I picked a random value. Once again, if this works
>                     for ICE, should work for DTLS just as well.____
>
>                     __ __
>
>                     Let me know if you have a better idea for ID
>                     generation.____
>
>                     __ __
>
>                     Regards,____
>
>                     _____________
>                     Roman Shpount____
>
>                     ____
>
>                 __ __
>
>             __ __
>
>         __ __
>
>     __ __
>
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 10 Mar 2016 21:38:26 -0500

How about the following?

dtls-association-id = 1*256alphanum

When new DTLS association is created, end point MUST ensure that
combination of dtls-association-id and all the fingerprint values is
unique. If end point creates one or more new self-signed certificate for
each new DTLS association, it can omit the dtls-association-id, since
fingerprint(s) will already guarantee high probability of uniqueness. If
end point creates and reuses all the certificate for multiple DTLS
associations, then dtls-association-id set to a simple counter value
incremented for each new DTLS association would guarantee sufficient
uniqueness. If pre-configured DTLS certificate is used across multiple end
points, then dtls-association-id should be set to a random value of
sufficient length, with at least 128 bits of randomness recommended.

_____________
Roman Shpount

On Tue, Mar 8, 2016 at 11:35 PM, Justin Uberti <[email-masked]> wrote:

>> fingerprints is for a newly generated self-signed certificate which
>> will not be reused for any other DTLS association.
>>
>> Regards,
>>
>> _____________
>> Roman Shpount
>>
>>> There is no need to track the “order” of DTLS associations, so I think
>>> we should use random value. I am not sure we need “+” and “-“. Would a
>>> numeric value be enough? The number of DTLS associations between the
>>> connected endpoints is going to be very small, so we shouldn’t
>>> over-engineer it.
>>>