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

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 24 February 2016 20:48 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2565B1B3FD6 for <mmusic@ietfa.amsl.com>; Wed, 24 Feb 2016 12:48:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIn34vhkdJl0 for <mmusic@ietfa.amsl.com>; Wed, 24 Feb 2016 12:48:31 -0800 (PST)
Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 583091B403A for <mmusic@ietf.org>; Wed, 24 Feb 2016 12:48:25 -0800 (PST)
Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-04v.sys.comcast.net with comcast id NLnX1s0082GyhjZ01LoQGa; Wed, 24 Feb 2016 20:48:24 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-09v.sys.comcast.net with comcast id NLoQ1s0023KdFy101LoQSq; Wed, 24 Feb 2016 20:48:24 +0000
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56CE1717.1060703@alum.mit.edu>
Date: Wed, 24 Feb 2016 15:48:23 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456346904; bh=5GyI74A9Hsu0OJ3DFdHiqm3NSZQ/whpQAjY/axfVBw8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=v2EhOossisZC8+03uyqp640hv1+3YqU7EY4a6mRka4PpVODSIMzlwZWb4ct5NFxeZ aF6UOOpPMZG66gZVLub/u9ycCnlororIV24rB1f1Jg4t2s6v/8urF+em/s1qJst70J QnSc5hi34mHG9rgcBpYDHKKMQLxS77R4HgVOEONlPZAkJt9+tjuXtYJ930gUceflzZ eN7YFKy2Oh/3pWPENVG/Ts8sunyY+lmgadDPRHp+dpX8yLAd3EYCXedn79q+MbILsP 818bw8G+6Iohf+QtFDVIg0klwODm3gQoRcNMbKhHyOBpi/av4nURxiThTrgxd02sE6 1DO8ULuo5gpWg==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/3B9yB3un94jVLxDiAZvvlvfoJsI>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Feb 2016 20:48:33 -0000

Christer,

On 2/24/16 3:26 PM, Christer Holmberg wrote:
> Hi,
>
> ...
>
>   --------------------
>
>>>> * 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".

That would work. But maybe this should wait for clarification on the use 
of multiple fingerprints.

>> 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.

I sent a separate reply on this, asking Jonathan to comment.

> --------------------
>
>>>> * 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.

Now that we have discussed it, I agree that this is sufficient.

> 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.

Yes. I'm not sure if this is needed.

When setup is used with TCP/SCTP there may be cases where passive can't 
be supported, because incoming connection requests are blocked. (That 
was one of the reasons for negotiating this.) But I don't think that 
holds for DTLS if the transport has already been established. So AFAIK 
nothing should prevent either end from taking either role. So it might 
not need to be mentioned.

	Thanks,
	Paul