Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's substantive comments

Christer Holmberg <> Tue, 14 March 2017 20:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D372B1314A1; Tue, 14 Mar 2017 13:08:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.321
X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kG5_Oiz-92d1; Tue, 14 Mar 2017 13:08:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6994A13149D; Tue, 14 Mar 2017 13:08:00 -0700 (PDT)
X-AuditID: c1b4fb30-e63ff70000007738-c0-58c84d9e03d3
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id AA.C9.30520.E9D48C85; Tue, 14 Mar 2017 21:07:58 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Tue, 14 Mar 2017 21:07:58 +0100
From: Christer Holmberg <>
To: Ben Campbell <>
CC: "" <>, mmusic <>
Thread-Topic: AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's substantive comments
Date: Tue, 14 Mar 2017 20:07:57 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7iu483xMRBiseG1vM7zzNbrHj7g42 i6nLH7M4MHssWfKTyWPWzicsAUxRXDYpqTmZZalF+nYJXBndt46xFlzTrOh/pNnAeEaji5GT Q0LARGJ772+WLkYuDiGBdYwSWzfvYYJwFjNKbJ61mbmLkYODTcBCovufNkiDiICSxPPmrSwg NrNAscTyb19YQWxhgSiJhY8PMULUREvcOwsRFxGwkmi7dYkdZAyLgKrEmxsuIGFeAV+JXbOm go0REiiQ2HHqGVg5p4C9xKbXr8FsRgExie+n1jBBrBKXuPVkPhPEzQISS/acZ4awRSVePv7H CmErSTQuecIKsopZQFNi/S59iFZFiSndD9kh1gpKnJz5hGUCo+gsJFNnIXTMQtIxC0nHAkaW VYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiBkXJwy2+DHYwvnzseYhTgYFTi4S1gPREhxJpY VlyZe4hRgoNZSYT3tA9QiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/ZyvvhQgLpiSWp2ampBalF MFkmDk6pBkauJRKTV9r9dvX98fXSa3Wv4EfLPKqEEuImXAj2NvdvvjBJonPq+a5nzLl75s/f f9vpdMpL7YTE92luRpqP2OTPL9/GdPc3lx2DHvcy77qfKj0NMdYcfRujjbXlG9h25dsHTnv2 uNXe/dnORx1enJssf9aWLyvav/esqcAhl79hgUuuOpRZX1BiKc5INNRiLipOBAD25FThkAIA AA==
Archived-At: <>
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's substantive comments
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Mar 2017 20:08:02 -0000


Substantive Comments:

>>> - section 4: "If an offer or answer does not
>>>    contain a ¹dtls-id¹ attribute (this could happen if the offerer or
>>>    answerer represents an existing implementation that has not been
>>>    updated to support the ¹dtls-id¹ attribute), the offer or answer 
>>>    MUST be treated as if no ¹dtls-id¹ attribute is included. "
>>> That seems to say that if dtls-id is not included, the offer or 
>>> answer must be treated as if it's not included. Since that's 
>>> tautologically true, I suspect you meant to say something more?
>> This is related to the first sentence, saying that there is no default 
>> value defined for the attribute.
>> I could say "Hence, if an offer or answer does not contain", if it 
>> makes the text more clear.
> You would still get a sentence of the form "If not foo, then not foo." 
> Perhaps the predicate clause could be recast as the consequences or (high level) receiver behavior 
> when dtls-id not being present? Does the absence mean that the session is not setup? That the receiver assumes 
> the sender is a legacy implementation?

That the receiver assumes the sender is a legacy implementation.

Maybe something like:

   "No default value is defined for the SDP 'dtls-id' attribute.
   Implementations that wish to use the attribute MUST explicitly
   include it in SDP offers and answers.  If an offer or answer does not
   contain a 'dtls-id' attribute (this could happen if the offerer or
   answerer represents an existing implementation that has not been
   updated to support the 'dtls-id' attribute), unless there is
   another mechanism to explicitly indicate that a new DTLS association
   is to be established, a modification of one or more of the following
   characteristics MUST be treated as an indication that an endpoint
   wants to establish a new DTLS association:" 


>>> -10:
>>> If you accept my suggestion to move from 4474 to 4474bis in the 
>>> updated text for 5763, that will create changes that should probably 
>>> be mentioned here. For example, 4474bis signatures cover fewer things 
>>> than do 4474 signatures. The hope that 4474bis may be more deployable 
>>> than 4474, and therefore really used, may also be worth a mention 
>>> here.
>> RFC 5763 contains 20+ references to RFC 4474, in a number of different 
>> sections.
>> We would have to update all of those sections (at least the reference, 
>> possibly also normative text), because I don¹t think we should mix
>> 4474 and 4474bis. In my opinion, that should be done as a separate task.
> I scanned 5763 for the references to see if we could reasonably say that all references should be updated. 
> But there's some text on the limitations of identity for phone numbers that might become obsolete if we did that.
> SO I can be convinced to leave that out of scope for this update. But it's still a bit unfortunate :-)
> Would it make sense for this document to contain a paragraph somewhere mentioning that, since the publication 
> of 5763, RFC4474 is being updated to address some of those issues, and that implementors should at least consider 
> moving to it? The reason I push on this is that I have hopes that 4474bis can enable the dtls-srtp framework to be 
> used in a more secure fashion that typical for now, since we have such limited deployment of 4474.

"NOTE: Since the publication of RFC 5763, RFC 4474 has been obsoleted by draft-ietf-stir-4474bis. The updating of the references (and the
associated procedures) within RFC 5763 is outside the scope of this document. However, implementers of RFC 5763 applications are 
encouraged to implement draft-ietf-stir-4474bis instead of RFC 4474."

Feel free to modify, if you e.g., want to give more background etc about 4474bis.