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

[Roman Shpount <[e-mail]>]

How about the following?

dtls-association-id-attr = "dtls-association-id" ":" dtls-association-id

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 <[e-mail]> wrote:

> 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 <[e-mail]> 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 <
>> [e-mail]> 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 <[e-mail]>
>>> Date: Tuesday 8 March 2016 at 06:24
>>> To: Justin Uberti <[e-mail]>
>>> Cc: "[e-mail]" <[e-mail]>, Christer Holmberg <
>>> [e-mail]>, "[e-mail]" <[e-mail]>
>>> 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 <[e-mail]>
>>> 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 <[e-mail]>
>>>> wrote:
>>>>
>>>>>
>>>>> On Mon, Mar 7, 2016 at 12:21 PM, Paul Kyzivat <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> On 3/7/16 12:12 PM, Roman Shpount wrote:
>>>>>>
>>>>>>> On Mon, Mar 7, 2016 at 11:52 AM, Paul Kyzivat <[e-mail]
>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>
>>>>>>>     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?
>>>>>
>>>>>
>>>>> This is reusing the definition (and generation code) from ice-ufrag
>>>>> attribute (https://tools.ietf.org/html/rfc5245#section-15.4).
>>>>>
>>>>>     - 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.)
>>>>>>
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>