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

[Justin Uberti <[e-mail]>]

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

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

> So, alphanumeric it is :)
>
>
>
> *From:* Justin Uberti [mailto:[e-mail]]
> *Sent:* 09 March 2016 06:35
> *To:* Roman Shpount <[e-mail]>
> *Cc:* Christer Holmberg <[e-mail]>; Paul Kyzivat <
> [e-mail]>; [e-mail]
>
> *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 <[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
>
>
>
>
>
>
>
>
>
>
>