Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt

Christer Holmberg <> Wed, 24 February 2016 20:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4A5851A8A68 for <>; Wed, 24 Feb 2016 12:26:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2rAqA-2T_Q7S for <>; Wed, 24 Feb 2016 12:26:31 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1626E1B3EDE for <>; Wed, 24 Feb 2016 12:26:30 -0800 (PST)
X-AuditID: c1b4fb3a-f79ce6d000005138-01-56ce11f44aa3
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id F7.A0.20792.4F11EC65; Wed, 24 Feb 2016 21:26:29 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Wed, 24 Feb 2016 21:26:28 +0100
From: Christer Holmberg <>
To: Paul Kyzivat <>, "" <>
Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt
Thread-Index: AQHRYDJWlchfH5W0vky7ZrpRmrhLnJ83E66AgAJUQ1CAALVrAIAA3K9AgACCd4CAAECHsA==
Date: Wed, 24 Feb 2016 20:26:27 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7ve5XwXNhBncXMFlMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG+hn7GAv6lSqWPrjP3sD4V6qLkYNDQsBE YsqnxC5GTiBTTOLCvfVsXYxcHEIChxklmlo2sEA4ixklfl3sYQZpYBOwkOj+pw3SICLgK/Hs 8W02EFtYwF7i3/0PbBBxB4lNN64xQthhEkseTmIFsVkEVCXW7m1nB7F5gXofNTUwQcyfyCQx ZftBsGZOAR2JEy+XghUxAl30/dQaJhCbWUBc4taT+UwQlwpILNlznhnCFpV4+fgfK4StJNG4 5AkrRL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMYoWpxYX 56YbGemlFmUmFxfn5+nlpZZsYgTGycEtv612MB587niIUYCDUYmHd8Pfs2FCrIllxZW5hxgl OJiVRHjXc5wLE+JNSaysSi3Kjy8qzUktPsQozcGiJM67xnl9mJBAemJJanZqakFqEUyWiYNT qoFRqjBU68vL9d+ZFWOeiF/+Y5HyfPKmMJO/M4I2fvxY7HfXZO9hYaeNlVvMNBOP5e6vVeBO ucs64SqH6+515073qebO4zP1PPlxKgtD4ty5IhwME+rmLl26L3barC0y95KP1Kn7N+782/N+ m9258/xMJZobszYsEEu4O6GFT3QX8+Sc/lzOW/+ElViKMxINtZiLihMBYAbCZI8CAAA=
Archived-At: <>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Feb 2016 20:26:33 -0000




>>> * Section 5.1:
>>>     The certificate received during the DTLS handshake MUST match the
>>>     fingerprint received in the SDP "fingerprint" attribute.  If the
>>>     fingerprint does not match the hashed certificate, then the endpoint
>>>     MUST tear down the media session immediately.  ...
>>> This talks about *the* fingerprint. But, IIUC, multiple fingerprints may be supplied. What is the required processing in that case?
>> We try to clarify that in section 3.4, which says:
>>     "It is possible to associate multiple SDP fingerprint attribute values
>>     to an 'm-' line.  If any of the attribute values associated with an
>>     'm-' line are removed, or if any new attribute values are added, it
>>     is considered a fingerprint value change."
> Right. But AFAIK that is the only place it is mentioned. At the least, most places that reference "the fingerprint" 
> should acknowledge that there may be more than one.

I guess we could use "one or more SDP 'fingerprint' attributes" terminology instead of "an SDP 'fingerprint' attribute".

> And *someplace* needs to say what the semantics of use are when there is more than one. (Maybe it is defined in one 
> of the references?) Am I correct in assuming that providing multiple fingerprints is for the convenience of the
> recipient, who can then pick the one that it prefers to verify?

I don't think the semantics are defined anywhere, unless it is defined in some RTCWEB document... I remember that it was agreed at some point that multiple fingerprints were allowed, but I am not sure whether anything was written down in a specificaiton...

In my opinion, the semantics belong to RFC 4572.


>>> * Section 5.3:
>>> If the offer specified 'existing' but the answerer changes to 'new', 
>>> should the setup attribute settings remain as they had been? (Which 
>>> then determines which end sends the ClientHello message.)
>> Not sure I understand. If a new DTLS association is to be established, shouldn't it be allowed 
>> to re-negotiate the roles (read: change the value of the 'setup' attribute)?
>> The problem is that the offerer specified "existing", and so followed the rules for doing that. So it had 
>> to use the last negotiated setup value. But the answerer has decided to switch to "new". At this point 
>> there are limits on what it can do - there can't be a full negotiation.
> If the offer contained "active" or "passive" then the answerer is stuck with what was previously negotiated. If the 
> offer contained "actpass" then maybe the answerer could choose either "active" or "passive" independent of what 
> was previously negotiated. I think this needs to be explained and clarified as to what is allowed.

Ok, now I understand.

The text does say that the 'setup' attribute must be set according to RFC 4572, so I think that covers what values are allowed.

But, perhaps we could add a note, saying that if the answerer is not able to able to select a 'setup' value that reflects it capabilities, it must reject the m- line. That of course also applies to the handling of the initial offer.



>> In addition, I noticed that the document uses "DTLS connection" terminology in a few places, while the 
>> intention is to use "DTLS association" (which is also used in the RFCs we update).
>> The question is whether the name of the SDP attribute should still be "dtls-connection", or whether we 
>> should change it to "dtls-association". My personal preference would be to keep the "dtls-connection" name, but I can live with both.
> On one hand using dtls-connection draws parallels with 'connection', which might be good.

Yes - that is exactly the reason why my preference is 'dtls-connection' :)

> On the other hand the parallels aren't complete, so maybe changing it would emphasize that it *isn't* the same.

Well, 'DTLS connection' is used in some specifications...

> And then it is rather last in the process to be making this change.
> I guess I'm neutral on this.

So, unless someone objects, I'll keep it as it is.