Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-02

Hi Martin,

Thanks for your comments! See inline.

>The conditions for " modification requires a new DTLS association"
>might need to be more clearly spelled out.  I think that this is based on some sort of local constraint, but you should say as much.

Ok, we'll think of something.

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

>Section 2 can be removed.

Unless we put some content (other than "TBD") there, it will be removed.

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

> I think that the definition of fingerprint change is problematic.  I think that you should require that a partial change to the set of fingerprints is also accompanied 
> by signaling rather than mandating a new DTLS connection.  If - for example - a fingerprint that is not in use is removed, then I think that some existing implementations 
> will expect to continue.

My assumption is that all changes that mandate a new DTLS  connection are accompanied by signalling. But, I agree that it needs to be more clear.

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

>I don't like the cipher suite requirements.  They don't match those for WebRTC for starters.  I'd prefer to see them excised.  I'd be OK with a recommendation to prefer forward secrecy or even to require it.
>
>I don't mind the fingerprint requirements (SHA-256 and the must match rule).  I'm not sure how others feel about restating 5763 requirements, though I think that this is OK.

The requirements are taken from RFC 7345. We were asked by the security folks to include them.

I can remove it, but there is a risk it will come up again during the IESG/security review...

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

>"It is considered an error case if the answer contains a 'dtls-connection' attribute with an 'existing' value, and a DTLS association does not exist." -- What do you expect someone to do in this case?

Normally the action in cases like this is "based on local policy". I guess we can say that the offerer MUST NOT assume that a DTLS association has been created.

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

>You missed the most important consideration: when running a second DTLS association over the same transport, it is difficult to distinguish between the first 
> and second association because DTLS packets don't identify themselves externally [4].  This point is important enough to include in the intro in my opinion, though 
> I would also add a sub-section to Section 4 explaining this in more detail.

We were going to add text about that, but it seems like we forgot.

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

> I'm not sure about 8.1.  I think that a key insight here is that the connection-oriented transport might not be end-to-end.  That suggests that multiple DTLS associations 
> can be established.  Based on that, you might suggest that connection-oriented transports are no different to any other transport.

I'll let Roman reply to this one.

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

> I found Section 10 basically impossible to parse: patches like this are very hard to read and it's half the document!  I'd rather have a short statement identifying 
> the nature of the changes.  

My suggestion is to keep the current changes, but to add some text describing the changes.

> I think that the 5245 change is incorrect though because it loses some important details.

Do you mean some other RFC? The draft does not update RFC 5245. Or, do you mean that some reference to RFC 5245 is incorrect?

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

>Nits:
>In 6.3: "and determines (based on the criteria for establishing a new DTLS association)" needs a reference.

Will be fixed.

>In 6.4: "if the offerer becomes DTLS client, the offerer MUST establish a DTLS association." Might be worth mentioning that this is based on a=setup.

Will be fixed.

Thanks!

Regards,

Christer

[4] Unless you are lucky enough to have different epochs, but don't do that.  Ever.

On 8 December 2015 at 18:48, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
> Hi,
>
>
>
> A new version (-02) of draft-ietf-mmusic-dtls-sdp-02 has been submitted.
>
>
>
> Note that this version now suggests updates to RFC 5763 (SRTP-DTLS) 
> and RFC
> 7341 (UDPTL-DTLS), so I encourage people to take a look.
>
>
>
> In addition, there is some new text about re-using connection-oriented
> (read: acknowledged packet delivery) for establishing a new DTLS 
> association.
>
>
>
> You can also find the document on github:
> https://github.com/cdh4u/draft-dtls-sdp
>
>
>
> (NOTE: This is my personal repo, as I am not aware of any “official” 
> MMUSIC
> repo)
>
>
>
> Regards,
>
>
>
> Christer
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>