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

[Paul Kyzivat <[e-mail]>]

On 3/10/16 8:55 PM, Justin Uberti wrote:
> 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
> <[e-mail] <mailto:[e-mail]>>
> wrote:
>
>     So, alphanumeric it is :)____
>
>     __ __
>
>     *From:*Justin Uberti [mailto:[e-mail]
>     <mailto:[e-mail]>]
>     *Sent:* 09 March 2016 06:35
>     *To:* Roman Shpount <[e-mail] <mailto:[e-mail]>>
>     *Cc:* Christer Holmberg <[e-mail]
>     <mailto:[e-mail]>>; Paul Kyzivat
>     <[e-mail] <mailto:[e-mail]>>;
>     [e-mail] <mailto:[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]
>     <mailto:[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]
>         <mailto:[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]
>             <mailto:[e-mail]>>
>             *Date: *Tuesday 8 March 2016 at 06:24
>             *To: *Justin Uberti <[e-mail]
>             <mailto:[e-mail]>>
>             *Cc: *"[e-mail] <mailto:[e-mail]>"
>             <[e-mail] <mailto:[e-mail]>>,
>             Christer Holmberg <[e-mail]
>             <mailto:[e-mail]>>, "[e-mail]
>             <mailto:[e-mail]>" <[e-mail]
>             <mailto:[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] <mailto:[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] <mailto:[e-mail]>> wrote:____
>
>                     __ __
>
>                     On Mon, Mar 7, 2016 at 12:21 PM, Paul Kyzivat
>                     <[e-mail]
>                     <mailto:[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]>
>                             <mailto:[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____
>
>                     ____
>
>                 __ __
>
>             __ __
>
>         __ __
>
>     __ __
>
>