From nobody Mon Apr 4 01:49:04 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFAA812D0AF for ; Mon, 4 Apr 2016 01:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Tu0AVdHlv3OU for ; Mon, 4 Apr 2016 01:49:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B42412D0A5 for ; Mon, 4 Apr 2016 01:49:01 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 5A1F2F1B95ACD for ; Mon, 4 Apr 2016 08:48:58 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u348mxRP023788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 4 Apr 2016 08:48:59 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u348mxlp005961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 4 Apr 2016 10:48:59 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.83]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 4 Apr 2016 10:48:59 +0200 From: "Schwarz, Albrecht (Nokia - DE)" To: "mmusic@ietf.org" Thread-Topic: I-D Action: draft-schwarz-mmusic-t140-usage-data-channel-03.txt Thread-Index: AQHRjkx2EVvEdfa9PEOSE8DsquXfXZ95fv2g Date: Mon, 4 Apr 2016 08:48:59 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1ACE1A15EF8@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <20160404083126.15645.87658.idtracker@ietfa.amsl.com> In-Reply-To: <20160404083126.15645.87658.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [MMUSIC] FW: I-D Action: draft-schwarz-mmusic-t140-usage-data-channel-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 08:49:04 -0000 fyi, only keep-alive updates related DC candidate protocols No. 2 and 3 (T.= 140 & BFCP): draft-schwarz-mmusic-t140-usage-data-channel-03.txt draft-schwarz-mmusic-bfcp-usage-data-channel-02.txt The technical work is currently suspended due to the dependency on "DC prot= ocol No.1 'MSRP'": draft-ietf-mmusic-data-channel-sdpneg draft-ietf-mmusic-msrp-usage-data-channel As you know there is currently a side discussion ongoing related the princi= ple proceeding how the correspondent IANA registry should be architected. (See agenda: 11:30-11:50 IANA Registry Structure for SDP Attributes (20 min= s, Christian Groves & Paul Kyzivat) Regards, Albrecht -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of EXT = internet-drafts@ietf.org Sent: Montag, 4. April 2016 10:31 To: i-d-announce@ietf.org Subject: I-D Action: draft-schwarz-mmusic-t140-usage-data-channel-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : T.140 Text Conversation over Data Channels Authors : Keith Drage Juergen Stoetzer-Bradler Albrecht Schwarz Filename : draft-schwarz-mmusic-t140-usage-data-channel-03.txt Pages : 19 Date : 2016-04-04 Abstract: This document specifies how the ITU-T Protocol for multimedia application text conversation (Recommendation ITU-T T.140) can be instantiated as a data channel sub-protocol, using the SDP offer/answer exchange-based external negotiation defined in [I- D.ietf-mmusic-data-channel-sdpneg]. Two network configurations are documented: a WebRTC end-to-end configuration (connecting two T.140 over data channel endpoints), and a gateway configuration (connecting an T.140 over data channel endpoint with an T.140 over RTP/UDP endpoint). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-schwarz-mmusic-t140-usage-data-chann= el/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-schwarz-mmusic-t140-usage-data-channel-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-schwarz-mmusic-t140-usage-data-ch= annel-03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt From nobody Mon Apr 4 06:11:58 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C6512D585 for ; Mon, 4 Apr 2016 06:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 4enOFwLpfvHR for ; Mon, 4 Apr 2016 06:11:51 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F064612D5EB for ; Mon, 4 Apr 2016 06:11:26 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id d68so113216678ywe.1 for ; Mon, 04 Apr 2016 06:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=K25cjbPJD7voUokwgTt20qR4GCS/HD5TOGCE4qO3myQ=; b=DoQa5CfOQdUyLZBEYdxW+3F6uQc2fFAwU5DEd0evFWLtg6EvU93JaPE84/Tfkm6vVB iZ9dmHfcRN7tgEStWucrdKrTNDgFDXmOjQb7ZWC462xJInxw11izeWdcLIIYxeJh5BHZ Ez8NSMlK1Td6/b9XCVYn310TD/wd7gn9g9vKRjcpsQGDCOlK3pY0IaqXMGv4ToCckmFT THblUT+ppBYymnT+HVDHPQdgH4m5y5HKY8kH5rF3IbtzdedhPALk8LQH0kCujUDtDLD3 c0Ezz3w8YWlOy7IkVU7aSVOR3c76wI763I8FGv8O6yNeLWUehuwfxgY7bbZasJ8IhnRt vW7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=K25cjbPJD7voUokwgTt20qR4GCS/HD5TOGCE4qO3myQ=; b=N4mAuVkGSsBGymnOcmpm9e7Ctu96EEveOf46gIGokBq80UjmC5fYR6iA8kKHHBBw68 svrecmgPijxfDrktw035vDyp8T4UggxvQiB3wEIwy5GddE4k3qVs8LJpZcb7XMPaPHK7 069fvMYzcr/N+bkkLoKQnpQaUji1FXoyMVYSIdhjHHpTcQpikjAFFv3QnPJFj8F5Codl DbDBSqaT9uKBO5kvUBG+eLhbdxJxENrYRBEdyw2vf1E1cESetVWa0V5QUql26ZaXL2k5 f7UE/1DjqIB/uWqhtgTzmLxAQ4+r/TmuEhfpNxihp+1g43NBv2f0uAQSpuaOD0eGkwV2 MxJQ== X-Gm-Message-State: AD7BkJJDIvCbuGpy6V+ilUpZ7Tl5cEMfNYupSQvpdV5T7jLjkKrkkvxUSj2LCdNEMqN5sO3ZK0Z7rTydEu+huA== X-Received: by 10.13.193.4 with SMTP id c4mr5386834ywd.192.1459775486196; Mon, 04 Apr 2016 06:11:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Mon, 4 Apr 2016 06:10:46 -0700 (PDT) From: Eric Rescorla Date: Mon, 4 Apr 2016 10:10:46 -0300 Message-ID: To: mmusic WG , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a114caa9e4eaa62052fa87745 Archived-At: Subject: [MMUSIC] Tunnelling DTLS in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 13:11:53 -0000 --001a114caa9e4eaa62052fa87745 Content-Type: text/plain; charset=UTF-8 Hi folks, I wanted to call your attention to a draft I just published with a possibly stupid idea. https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 A nontrivial fraction of call setup time in WebRTC is the DTLS handshake. This document describes how to piggyback the first few handshake messages in the SDP offer/answer exchange, thus reducing latency. Comments welcome. -Ekr --001a114caa9e4eaa62052fa87745 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks,

I wanted to call your attenti= on to a draft I just published with a possibly stupid
idea.
=



Comments welcome.

-Ekr



--001a114caa9e4eaa62052fa87745-- From nobody Mon Apr 4 08:53:16 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C3212D603 for ; Mon, 4 Apr 2016 08:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 pHBbClSAqDsr for ; Mon, 4 Apr 2016 08:53:13 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31DD812D5FE for ; Mon, 4 Apr 2016 08:53:13 -0700 (PDT) Received: by mail-ig0-x229.google.com with SMTP id g8so35177583igr.0 for ; Mon, 04 Apr 2016 08:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=nwfe2jg/zA+WfPnuTDI9eM5g4s0IxSFBLbPK0VkIMXc=; b=LuWLSecE0A0bPEgMO4FkPp4KA8nENrerMTiPKxfSZb7MGihfA6mlgo4VRcbt2R7Y96 XoySA4U25zAxMMGEmFSIvgtGYjttgNg118opR92B7ZNDesUBLDKJ540barxeAQIGS+bW ghy9IZU9L5O5JKzZ+9b4kcOApKZBYunytDinnUuISWQeO+QIXx6MAf+8vL3sE0a03p7Q OG++kccIgCb4B4aPJxtNuNUhj55YLIaX4oIYKt/BRFVpJlQ1wp08QUFJGbCrQL6jVexk +ZTcbtVpWT2uuXU+hzf7aarNVOuwkumaJpATn3VHkRVyk04lePFEK21txC2kCUXj7Bg7 rzcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=nwfe2jg/zA+WfPnuTDI9eM5g4s0IxSFBLbPK0VkIMXc=; b=M0l/ws/c7buEdg4QUrH6uZu4rh1iP6dTXKw3wrOVg06Bva+eK+vWZXdJLJ33iC2PKM IRO3a6SM+HQONmoSOqx+HRgcH4dT4HGlPsUfp4vhAncxjzwScLUj9DS70cQYG9AsBdaU FT44bkDCCVJzhr1w8DrfMXdUw9AnQmHBCP+Ops7fBrDSPUitbIaVX70l4R9VSjpbhCDT StVsIZ0crbPu0XYduOV5xtefnVWbV2hvgLXGhkLTsaxP8WAEXxrh1f3vdi7+0ohkXOVj 87Zat0v6R2fyFoXedE2GZygY0ainwwQDzFs6F1dYWQOG68mSXF5f9dT2GpB+ZS25Q1GI YxXA== X-Gm-Message-State: AD7BkJLK5YLd8a2cWmNBhJqsjJRPcTTQFW1RU/wFXNtzLCHdYJ/jEQsB1BB5+aJxPC/BlA== X-Received: by 10.107.137.72 with SMTP id l69mr8111840iod.177.1459785185417; Mon, 04 Apr 2016 08:53:05 -0700 (PDT) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com. [209.85.213.180]) by smtp.gmail.com with ESMTPSA id p1sm11850566iop.12.2016.04.04.08.53.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2016 08:53:05 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id gy3so35129605igb.1; Mon, 04 Apr 2016 08:53:05 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.30.71 with SMTP id e68mr8044333ioe.145.1459785168790; Mon, 04 Apr 2016 08:52:48 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Mon, 4 Apr 2016 08:52:48 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 Apr 2016 11:52:48 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1140d71e6f72a6052faab865 Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 15:53:15 -0000 --001a1140d71e6f72a6052faab865 Content-Type: text/plain; charset=UTF-8 The proposal makes sense to me. 1. Why do you need to send both fingerprints and certificates in answer? If certificate is sent, fingerprint can be calculated from it and will be completely redundant. 2. Can you show where and how the DTLS-SRTP keys are going to be sent? I assume they will be transmitted together with ChangeCipherSpec. I think sending certificate in the answer instead of data path does not compromise security since if signaling path is compromised, data traffic can be redirected to MITM agent which can collect exactly the same data. This has the benefit over sending DTLS handshake using ICE/STUN messages that it does not need to deal with packet fragmentation and reassembly. Regards, _____________ Roman Shpount On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla wrote: > Hi folks, > > I wanted to call your attention to a draft I just published with a > possibly stupid > idea. > > https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 > > A nontrivial fraction of call setup time in WebRTC is the DTLS handshake. > This document describes how to piggyback the first few handshake messages > in the SDP offer/answer exchange, thus reducing latency. > > Comments welcome. > > -Ekr > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a1140d71e6f72a6052faab865 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The proposal makes sense to me.

1= . Why do you need to send both fingerprints and certificates in answer? If = certificate is sent, fingerprint can be calculated from it and will be comp= letely redundant.

2. Can you show where and how the DTLS= -SRTP keys are going to be sent? I assume they will be transmitted together= with=C2=A0ChangeCiphe= rSpec.

I think sending certificate in the answer instead = of data path does not compromise security since if signaling path is compro= mised, data traffic can be redirected to MITM agent which can collect exact= ly the same data.

This has the benefit over sending = DTLS handshake using ICE/STUN messages that it does not need to deal with p= acket fragmentation and reassembly.

<= font color=3D"#000000">Regards,<= /font>
______= _______
Roman Shpount

On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorl= a <e= kr@rtfm.com> wrote:
Hi f= olks,

I wanted to call your attention to a draft I just = published with a possibly stupid
idea.

<= a href=3D"https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00" target= =3D"_blank">https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00

A nontrivial fraction of call setup time in Web= RTC is the DTLS handshake.
This document describes how to piggyba= ck the first few handshake messages
in the SDP offer/answer excha= nge, thus reducing latency.

Comments welcome.

-Ekr




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--001a1140d71e6f72a6052faab865-- From nobody Mon Apr 4 10:34:35 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0C812D60F; Mon, 4 Apr 2016 10:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 UCkB8yPx8Xwz; Mon, 4 Apr 2016 10:34:30 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5094712D12E; Mon, 4 Apr 2016 10:34:30 -0700 (PDT) Received: by mail-ig0-x231.google.com with SMTP id g8so40346015igr.0; Mon, 04 Apr 2016 10:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=TokuKdW0ADzGH3lJNCaQsMCzI3ZR9tsLGNUolC2Woa0=; b=HQcfMMvhN+lyb38nFTYVYsy39FEJKpZvLwmNIb7sbsUl7LgmDmNZe4CN8haJw90nBH PVeWP+lLZv5ZoHhR3JOTuR8VmBwc479iPV4ODYbVcVsCjWPA0wZSuDy6V9tCOJWPoDeP VVBpHZ8fSDaAEX/+oSNh7N2U016TdtZWRCZ6MIdRxxk4FScDD0NLmjDG3Lo38tEGfw+V Tarn43tqILQq8mqWyKvq4Y9ErVKsIxI6mJWEXmcws2k1AK68k08aagBA6kgjc7jkSLT1 dLyUdv07bor35y5CFd7LMwtajwnUtTmCPkLQD5QUHy+peEu4rx8s+u/CAAFv8EnWCUJX djgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=TokuKdW0ADzGH3lJNCaQsMCzI3ZR9tsLGNUolC2Woa0=; b=ljTdjwvZ2sHpQP5zr1C/HYrfttj4JNMLNz0QAUK0Ut2nElql+kAtGU+/1oN1QdVAgg ZL+06ffMb2W6vmBe48VUDtuynXxpQct1hJVfVEAj9RlBGcrMIiVY+p7bMVKoWzhDSysn +QZdlUSuKWz6gYQtFJeiwYA9DyRvM+PXVREFcUZjALWq5mMAyOALrgTD8mH7quBN8Voi DaQo8qJitMN78Wk89WA/Wh4t2MuIw1Jv/r8fKFOkgVIs1f7lCogdWata5Z3R/pNXDugy dpS7FzILHRkXvJycUIaBi7WQNdTx0gCErTKOa0lSCi0XxpvBxtpnlX1yP3iyjvu2dwjf dlTA== X-Gm-Message-State: AD7BkJJ4AC3lUxZPPkp5aGPydsdQSVcuBJZKe98x220ZfYSakl/BzASc+IxQ2JIwmMzcL5kkeEXqRE3B6jQGjw== MIME-Version: 1.0 X-Received: by 10.50.221.67 with SMTP id qc3mr12769650igc.77.1459791269598; Mon, 04 Apr 2016 10:34:29 -0700 (PDT) Received: by 10.36.43.5 with HTTP; Mon, 4 Apr 2016 10:34:29 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 Apr 2016 14:34:29 -0300 Message-ID: From: Martin Thomson To: pfh Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 17:34:32 -0000 On 4 April 2016 at 12:39, pfh wrote: > It strikes me we could get the same reduced latency benefits by piggybacking > on ICE > rather than SDP, e.g. embedding the DTLS packet as data in a new STUN > attribute type. One of the goals for connectivity checks is to keep them small. Cramming DTLS in is not compatible with this. From nobody Mon Apr 4 11:02:39 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7815412D0B9; Mon, 4 Apr 2016 11:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lcJ1lA5APsH; Mon, 4 Apr 2016 11:02:35 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928F612D0B0; Mon, 4 Apr 2016 11:02:34 -0700 (PDT) X-AuditID: c1b4fb25-f79f86d00000400a-0e-5702ac38ca98 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B7.E9.16394.83CA2075; Mon, 4 Apr 2016 20:02:32 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0248.002; Mon, 4 Apr 2016 20:02:32 +0200 From: Christer Holmberg To: Eric Rescorla , mmusic WG , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Tunnelling DTLS in SDP Thread-Index: AQHRjnOQTXAAgUuNbU6Yumm3JEpBMZ953U5w Date: Mon, 4 Apr 2016 18:02:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F218C3@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37F218C3ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2K7iq7FGqZwg/eL9S1WvD7HbjF1+WMW i7X/2tkdmD2WLPnJ5DH5cRtzAFMUl01Kak5mWWqRvl0CV8bR1/dZCy45V5zZ9JaxgfGBYxcj J4eEgInE9gV/mCFsMYkL99azdTFycQgJHGGUWDv3MpSziFFi95rt7F2MHBxsAhYS3f+0QRpE BFIkeo6dZASxhQV0JA4t2sgEEdeV2HdxNzuEbSRxb8sjsDiLgIrE41U/2UDG8Ar4Slx6VwgS FhIIkLjx8B/YGE6BQIkju5+A3cMIdM/3U2vAWpkFxCVuPZnPBHGngMSSPeehbhaVePn4HyuE rSTRuOQJK8h4ZoF8iRdXTEHCvAKCEidnPmGZwCgyC8mkWQhVs5BUQYQ1Jdbv0oeoVpSY0v2Q HcLWkGidM5cdWXwBI/sqRtHi1OKk3HQjY73Uoszk4uL8PL281JJNjMDIOrjlt+oOxstvHA8x CnAwKvHwLjjFGC7EmlhWXJl7iFGCg1lJhLdlJVO4EG9KYmVValF+fFFpTmrxIUZpDhYlcd7s yH9hQgLpiSWp2ampBalFMFkmDk6pBkbXmvWbrmX8CNn+0EHLa1dA2cTqHbH/uEKuBimHijyM l3DLZ5t7O0eizlbh4YMut4S38QtnnuDg2nDpz7WvXhv6f6Yc23b0tg9z2o2qz19ePmW2CK5r bxBIyJ/P78amsmWHvuWB359WW6+pm7eRS8r22Od3qqyGBs9jXt1guaLrt/V2T9zb/+xKLMUZ iYZazEXFiQAlEwhmqAIAAA== Archived-At: Subject: Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 18:02:37 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37F218C3ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClJlZ2FyZGluZyBmb3JraW5nLCB5b3UgY2Fubm90IGFzc3VtZSB0aGF0IGZvcmtpbmcg ZW50aXRpZXMgd2lsbCByZW1vdmUgdGhlIFNEUCBhdHRyaWJ1dGUuIFVubGVzcyB0aGV5IHN1cHBv cnQgdGhlIGF0dHJpYnV0ZSwgdGhleSB3aWxsIG1vc3QgbGlrZWx5IGp1c3QgZm9yd2FyZCBpdC4g VGhlIG9mZmVyZXIgd2lsbCBmaW5kIG91dCBpZiBmb3JraW5nIGhhcyBvY2N1cnJlZCwgYnV0IGhl IGFuc3dlcmVyKHMpIHdpbGwgbm90IGtub3cuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZy b206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg RXJpYyBSZXNjb3JsYQ0KU2VudDogMDQgQXByaWwgMjAxNiAxNjoxMQ0KVG86IG1tdXNpYyBXRyA8 bW11c2ljQGlldGYub3JnPjsgcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0OiBbcnRjd2ViXSBUdW5u ZWxsaW5nIERUTFMgaW4gU0RQDQoNCkhpIGZvbGtzLA0KDQpJIHdhbnRlZCB0byBjYWxsIHlvdXIg YXR0ZW50aW9uIHRvIGEgZHJhZnQgSSBqdXN0IHB1Ymxpc2hlZCB3aXRoIGEgcG9zc2libHkgc3R1 cGlkDQppZGVhLg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmVzY29ybGEt ZHRscy1pbi1zZHAtMDANCg0KQSBub250cml2aWFsIGZyYWN0aW9uIG9mIGNhbGwgc2V0dXAgdGlt ZSBpbiBXZWJSVEMgaXMgdGhlIERUTFMgaGFuZHNoYWtlLg0KVGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgaG93IHRvIHBpZ2d5YmFjayB0aGUgZmlyc3QgZmV3IGhhbmRzaGFrZSBtZXNzYWdlcw0KaW4g dGhlIFNEUCBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UsIHRodXMgcmVkdWNpbmcgbGF0ZW5jeS4NCg0K Q29tbWVudHMgd2VsY29tZS4NCg0KLUVrcg0KDQoNCg0K --_000_7594FB04B1934943A5C02806D1A2204B37F218C3ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkaW5nIGZv cmtpbmcsIHlvdSBjYW5ub3QgYXNzdW1lIHRoYXQgZm9ya2luZyBlbnRpdGllcyB3aWxsIHJlbW92 ZSB0aGUgU0RQIGF0dHJpYnV0ZS4gVW5sZXNzIHRoZXkgc3VwcG9ydCB0aGUgYXR0cmlidXRlLCB0 aGV5IHdpbGwNCiBtb3N0IGxpa2VseSBqdXN0IGZvcndhcmQgaXQuIFRoZSBvZmZlcmVyIHdpbGwg ZmluZCBvdXQgaWYgZm9ya2luZyBoYXMgb2NjdXJyZWQsIGJ1dCBoZSBhbnN3ZXJlcihzKSB3aWxs IG5vdCBrbm93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh IG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5T ZW50OjwvYj4gMDQgQXByaWwgMjAxNiAxNjoxMTxicj4NCjxiPlRvOjwvYj4gbW11c2ljIFdHICZs dDttbXVzaWNAaWV0Zi5vcmcmZ3Q7OyBydGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gW3J0Y3dlYl0gVHVubmVsbGluZyBEVExTIGluIFNEUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhpIGZvbGtzLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSB3YW50ZWQgdG8gY2FsbCB5b3VyIGF0dGVudGlvbiB0byBhIGRyYWZ0 IEkganVzdCBwdWJsaXNoZWQgd2l0aCBhIHBvc3NpYmx5IHN0dXBpZDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aWRlYS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlc2NvcmxhLWR0bHMtaW4tc2RwLTAwIj5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmVzY29ybGEtZHRscy1pbi1zZHAtMDA8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgbm9u dHJpdmlhbCBmcmFjdGlvbiBvZiBjYWxsIHNldHVwIHRpbWUgaW4gV2ViUlRDIGlzIHRoZSBEVExT IGhhbmRzaGFrZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0byBwaWdneWJhY2sgdGhlIGZpcnN0 IGZldyBoYW5kc2hha2UgbWVzc2FnZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmluIHRoZSBTRFAgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlLCB0aHVz IHJlZHVjaW5nIGxhdGVuY3kuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkNvbW1lbnRzIHdlbGNvbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B37F218C3ESESSMB209erics_-- From nobody Mon Apr 4 17:45:09 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B7312D1CD for ; Mon, 4 Apr 2016 17:45:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160405004508.15614.17591.idtracker@ietfa.amsl.com> Date: Mon, 04 Apr 2016 17:45:08 -0700 From: IETF Secretariat Archived-At: Subject: [MMUSIC] Milestones changed for mmusic WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 00:45:08 -0000 Changed milestone "Submit a framework for SDP attributes when multiplexing as Proposed Standard", resolved as "Done". Changed milestone "Submit IANA registrations of SDP 'proto' attribute for transporting RTP Media over TCP under various RTP profiles as Proposed Standard", resolved as "Done". Changed milestone "Submit SDP extension for cross session stream identification as Proposed Standard", set due date to April 2016 from December 2015. Changed milestone "Submit SDP Negotiation of DataChannel sub-protocols as Proposed Standard", set due date to May 2016 from December 2015. Changed milestone "Submit Using Simulcast in SDP and RTP Sessions as Proposed Standard", set due date to June 2016 from January 2016. Changed milestone "Submit RTP Payload Format Constraints as Proposed Standard", set due date to June 2016 from February 2016. Changed milestone "Submit SDP extensions to negotiate multiplexed media streams as Proposed Standard", set due date to July 2016 from December 2015. Changed milestone "Using the SDP Offer/Answer Mechanism for DTLS", set due date to September 2016 from February 2016. Changed milestone "Submit revised SDP specification to IETF as Proposed Standard", set due date to September 2016 from March 2016. Changed milestone "Submit MSRP over Data Channels as Proposed Standard", set due date to October 2016 from March 2016. Changed milestone "Submit SCTP-Based Media Transport in SDP as Proposed Standard.", set due date to October 2016 from May 2016. Changed milestone "Submit SIP usage for Trickle ICE as Proposed Standard", set due date to December 2016 from February 2016. Changed milestone "Submit Interactive Connectivity Establishment (ICE) with SDP offer/answer and SIP as Proposed Standard", set due date to December 2016 from April 2016. URL: https://datatracker.ietf.org/wg/mmusic/charter/ From nobody Mon Apr 4 18:38:07 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B75212D0F0 for ; Mon, 4 Apr 2016 18:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Q35kfuq4FKAn for ; Mon, 4 Apr 2016 18:38:03 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 786FA12D0A7 for ; Mon, 4 Apr 2016 18:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6313; q=dns/txt; s=iport; t=1459820283; x=1461029883; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=TcVmtMeMfZb413npaWIDKmGJIOHCbrGD9iabYkhLij4=; b=Emy8P61Y0Xfdd2yJDk/jme4/sNZ1rhWdmHegxWsMJW/Xj8+Pen1MEZyX DCdrleNjR4LBuGQf9zmIxkFvqUedvuGKJZ931Mn1F81Z9GKRdd1TMBAZj GmOzPf6pAXpDAhwJe7oCNKMm8Vh+43UxdOPxh3TSgH6SEJd4bIezz6jAi c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AsAgCjFQNX/4gNJK1dDoMpU327KAENg?= =?us-ascii?q?XIXCoUiSgKBPDgUAQEBAQEBAWUnhEEBAQEDAQEBATU2CgYLCw4KCRYPCQMCAQI?= =?us-ascii?q?BFTAGAQwGAgEBiBsIDr8CAQEBAQEBAQEBAQEBAQEBAQEBFASGIIRKihUBBI1Ni?= =?us-ascii?q?jSOCIk6hVWPGh4BAUKDLFcgMIgmAQEB?= X-IronPort-AV: E=Sophos;i="5.24,442,1454976000"; d="scan'208";a="90192990" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Apr 2016 01:38:02 +0000 Received: from [10.86.250.161] (bxb-vpn3-673.cisco.com [10.86.250.161]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u351c0Wt004920; Tue, 5 Apr 2016 01:38:00 GMT To: Paul Kyzivat , mmusic@ietf.org References: <56E1C193.1050308@alum.mit.edu> <56E2EF31.2020808@alcatel-lucent.com> <56E2F67D.7060005@alum.mit.edu> From: Flemming Andreasen Message-ID: <570316F6.4090806@cisco.com> Date: Mon, 4 Apr 2016 21:37:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56E2F67D.7060005@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] IANA registration of SDP attributes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 01:38:05 -0000 On 3/11/16 11:46 AM, Paul Kyzivat wrote: > On 3/11/16 11:15 AM, Juergen Stoetzer-Bradler wrote: >> Paul, >> >> The last alternative would have the advantage that different subprotocol >> documents could be referenced for the same attribute. Like e.g. for the >> setup attribute (if there were BFCP over data channel transport specific >> aspects): >> >> *SDP Name* *Level(s)* *Reference(s)* >> accept-types >> media, >> dcsa(MSRP) >> [RFC4975] >> [draft-ietf-mmusic-msrp-usage-data-channel] >> cat >> session >> [RFC4566] >> fmtp >> media,source [RFC4566][RFC5576] >> mediaclk >> session,media,source >> [RFC7273] >> ptime >> media >> [RFC4566] >> recvonly >> session,media, >> dcsa(MSRP) >> [RFC4566][RFC4975] >> [draft-ietf-mmusic-msrp-usage-data-channel] >> setup >> session, media >> dcsa(MSRP) >> dcsa(BFCP) >> [RFC4145] >> [draft-ietf-mmusic-msrp-usage-data-channel] >> [draft-schwarz-mmusic-bfcp-usage-data-channel] >> >> >> Therefore I'd be in favor of your last alternative. > > Let's see what other comments we get, especially from Flemming. > Thanks for putting this together Paul. My preference is also the last alternative. Thanks -- Flemming > Then, if this is preferred direction we can work on refining it. > > Thanks, > Paul > >> Thanks, >> Juergen >> >> >> On 10.03.2016 19:48, EXT Paul Kyzivat wrote: >>> [splitting off from the thread on data-channel-sdpneg] >>> >>> Currently IANA has five(!) separate registries for sdp attributes: >>> >>> att-field (session level) >>> att-field (both session and media level) >>> att-field (media level only) >>> att-field (source level) >>> att-field (unknown level) >>> >>> They all have the same format: >>> >>> *Type** >>> * *SDP Name** >>> * *Reference** >>> * >>> att-field (session level) cat [RFC4566] >>> att-field (both session and media level) recvonly >>> [RFC4566] >>> att-field (both session and media level) mediaclk >>> [RFC7273] >>> att-field (media level only) accept-types >>> [RFC4975] >>> att-field (media level only) fmtp >>> [RFC4566] >>> att-field (source level) fmtp >>> [RFC5576] >>> >>> >>> This format is a pain, because it is hard to look an attribute up if >>> you don't know at what level(s) it is valid. It also has the potential >>> to allow an attribute name to be registered for unrelated purposes if >>> the type is different. (IMO that would be bad.) >>> >>> A long time ago (several years now), as part of the 4566bis work, I >>> proposed that these tables be merged into one. It was my impression >>> that this was agreed and would be done. But I don't recall any >>> agreement on the logistics of doing so. >>> >>> My thought was that the combined table would look like: >>> >>> *SDP Name* *Level(s)* *Reference(s)* >>> accept-types >>> media >>> [RFC4975] >>> cat >>> session >>> [RFC4566] >>> fmtp >>> media,source [RFC4566][RFC5576] >>> mediaclk >>> session,media,source >>> [RFC7273] >>> ptime >>> media >>> [RFC4566] >>> recvonly >>> session,media >>> [RFC4566] >>> >>> >>> >>> Then we get to data channel attributes. My thought is to incorporate >>> them into this table structure, as yet another "level". E.g., >>> >>> *SDP Name* *Level(s)* *Reference(s)* >>> accept-types >>> media,dcsa >>> [RFC4975][draft-ietf-mmusic-msrp-usage-data-channel] >>> cat >>> session >>> [RFC4566] >>> fmtp >>> media,source [RFC4566][RFC5576] >>> mediaclk >>> session,media,source >>> [RFC7273] >>> ptime >>> media >>> [RFC4566] >>> recvonly >>> session,media,dcsa >>> [RFC4566][RFC4975][draft-ietf-mmusic-msrp-usage-data-channel] >>> >>> >>> (And this could also be extended for websockets if somebody proposes a >>> way to negotiate attributes for data channels too.) >>> >>> Using this format, if you want to know more than the name and the >>> level(s) at which it can be used you need to consult the references. >>> And when there are multiple references you don't know which one(s) you >>> need to consult. This can be "fixed" by including more information >>> from the reference into the registry. Conversely, we could strip it >>> down further and remove the levels from the registry - so you need to >>> consult the references for that too. >>> >>> For instance, if we wanted to simplify finding the right reference for >>> the level you are interested in, we could do: >>> >>> *SDP Name* *Level(s)* *Reference(s)* >>> accept-types >>> media, >>> dcsa >>> [RFC4975] >>> [draft-ietf-mmusic-msrp-usage-data-channel] >>> cat >>> session >>> [RFC4566] >>> fmtp >>> media,source [RFC4566][RFC5576] >>> mediaclk >>> session,media,source >>> [RFC7273] >>> ptime >>> media >>> [RFC4566] >>> recvonly >>> session,media, >>> dcsa >>> [RFC4566][RFC4975] >>> [draft-ietf-mmusic-msrp-usage-data-channel] >>> >>> >>> Or we could go further, and break the dcsa level down by subprotocol: >>> >>> *SDP Name* *Level(s)* *Reference(s)* >>> accept-types >>> media, >>> dcsa(MSRP) >>> [RFC4975] >>> [draft-ietf-mmusic-msrp-usage-data-channel] >>> cat >>> session >>> [RFC4566] >>> fmtp >>> media,source [RFC4566][RFC5576] >>> mediaclk >>> session,media,source >>> [RFC7273] >>> ptime >>> media >>> [RFC4566] >>> recvonly >>> session,media, >>> dcsa(MSRP) >>> [RFC4566][RFC4975] >>> [draft-ietf-mmusic-msrp-usage-data-channel] >>> >>> >>> Thoughts? >>> >>> Thanks, >>> Paul >>> >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From nobody Mon Apr 4 19:07:16 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9019412D0DB for ; Mon, 4 Apr 2016 19:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 ERVtGztEaW6L for ; Mon, 4 Apr 2016 19:07:12 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F0D12D5B0 for ; Mon, 4 Apr 2016 19:07:11 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id n3so2355097wmn.0 for ; Mon, 04 Apr 2016 19:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xyEz6gUQBQ+N4cC4fJPTd6mk1X/SkDxtCgtsYYLLJt8=; b=pp2XiFi0qojdr7/hNDY6aQUy0R6xcIMmgsOF9xUaJ4jG3EbEFTzTSM+E5SQWLlWMkh wKOL+i4PuHysmeSaGG5HicLoWHsd1mBQzGsteltZq2p4D6qRNudBR4QfiDeYW/vH4H90 b3mbn3aK0zIMVUILE0XxYb3+ZPHMPs7fIMDrlEDwSjv5TvILXHsY2pY8LF5n3M4Dh3wi FAgQ+RBmsLUsCMJBOxbHjW9F4sPzR6MoA9+21LqK+AZquNuhFGGazsc7W8/FmdwLh1JF 4aZQ4Obd93xDVI4CubJ0m9Efpgp26i8+xqvCzz3lX500PbrEh10frplGj/bT6okxmN24 brjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xyEz6gUQBQ+N4cC4fJPTd6mk1X/SkDxtCgtsYYLLJt8=; b=E0qzqTyKDqsf0Dz/6XhKCl6kBeHt+NIvEVvqR0nv4KGLMQJIq4au2HGZxzke+qkLba qEfyyfY1t7OwrHrePgZbqHGddQh2SsgMCc4x2j8q7D1srxN+VyXj265BwUOGNWrCn0nq tRXwHmRLm4qXncKW4eWTFGWt09yvnMh/6+538ECVl0JISr096SOmetb2bvNSbfOIb7NY QC0Lx3VFUPavCnk8ORUiGQpYyP1v6N1aeBg/PPyi9Gn/czEeVrioN+HYcxT/x3CVmkcn LtSsy3O0Rqq0kSVwFvCZfMptfcZ01yAMsjdqff5cADxIq6KBY+JIpw/6T2hixhS3R+59 Pb7w== X-Gm-Message-State: AD7BkJKuD2RqXkrlRYBMsVvoqUIKmw23t5XKLovjBNq67tJq0MYxotU0Rswkwrzy8Qs/kfUdNYvKD9WKDNjaD0FS X-Received: by 10.194.184.234 with SMTP id ex10mr20203229wjc.8.1459822029993; Mon, 04 Apr 2016 19:07:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.148.79 with HTTP; Mon, 4 Apr 2016 19:06:50 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Mon, 4 Apr 2016 19:06:50 -0700 Message-ID: To: pfh Content-Type: multipart/alternative; boundary=047d7b86cc1e88d08e052fb34d33 Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 02:07:14 -0000 --047d7b86cc1e88d08e052fb34d33 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 4, 2016 at 8:39 AM, pfh wrote: > > On 4 Apr 2016, at 14:10, Eric Rescorla wrote: > > Hi folks, > > I wanted to call your attention to a draft I just published with a > possibly stupid > idea. > > https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 > > A nontrivial fraction of call setup time in WebRTC is the DTLS handshake. > This document describes how to piggyback the first few handshake messages > in the SDP offer/answer exchange, thus reducing latency. > > > It strikes me we could get the same reduced latency benefits by > piggybacking on ICE > rather than SDP, e.g. embedding the DTLS packet as data in a new STUN > attribute type. > > The downside of piggybacking on the SDP is that you are increasing the > trust you have to place in the > signalling server undermining the elegant decoupling we have at the moment > between signalling and > media. (The SDES issues of logging keys in the web servers apply to the > public certs as well). > I don't think the logging issue applies here. Only the public key would be logged, and it's already transmitted in cleartext during a normal DTLS handshake (it's a public key, after all). > > It also significantly clutters the SDP (even more) ! > Please see Jonathan Lennox's comment about garbage piles. I think the only truly unattractive part here is the fact that the messages will need to be base64ed, resulting in minor blowup. But that seems like a reasonable downside for 1+ RTT upside. > As you point out, it weakens the usefulness of longer term certs, which > would be a major nuisance IMHO. > > Tim. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b86cc1e88d08e052fb34d33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 4, 2016 at 8:39 AM, pfh <tim@phonefromhere.com>= wrote:

On 4 Apr= 2016, at 14:10, Eric Rescorla <ekr@rtfm.com> wrote:

Hi f= olks,

I wanted to call your attention to a draft I just = published with a possibly stupid
idea.

<= a href=3D"https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00" target= =3D"_blank">https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00

A nontrivial fraction of call setup time in Web= RTC is the DTLS handshake.
This document describes how to piggyba= ck the first few handshake messages
in the SDP offer/answer excha= nge, thus reducing latency.

It strikes me we could get the same reduced latency benefits by p= iggybacking on ICE
rather than SDP, e.g. embedding the DTLS packe= t as data in a new STUN attribute type.

The downsi= de of piggybacking on the SDP is that you are increasing the trust you have= to place in the
signalling server undermining the elegant decoup= ling we have at the moment between signalling and=C2=A0
media. (T= he SDES issues of logging keys in the web servers apply to the public certs= as well).

I don't th= ink the logging issue applies here. Only the public key would be logged, an= d it's already transmitted in cleartext during a normal DTLS handshake = (it's a public key, after all).=C2=A0

It also sig= nificantly clutters the SDP (even more) !

Please see Jonathan Lennox's comment about garbage pil= es. I think the only truly unattractive part here is the fact that the mess= ages will need to be base64ed, resulting in minor blowup. But that seems li= ke a reasonable downside for 1+ RTT upside.


As you point out, it weakens the usefulness of longer term certs, whi= ch
would be a major nuisance IMHO.

Tim.<= /div>


_______________________________________________ rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--047d7b86cc1e88d08e052fb34d33-- From nobody Mon Apr 4 19:23:30 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB84C12D5A9 for ; Mon, 4 Apr 2016 19:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 d1i9Tkk3h-Ct for ; Mon, 4 Apr 2016 19:23:26 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6BA212D0F0 for ; Mon, 4 Apr 2016 19:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4439; q=dns/txt; s=iport; t=1459823006; x=1461032606; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=bnecTGbOpGN8bpeXjfR2RMUrUkgud6rt4pMGIdQdF2E=; b=MAYT6MrYsnDWEYcfgXd6UHJXKcgpsEjeoF8/Zbw47re2yrdUy2zFS5I7 cyVtwzNL+o6JLm/SH24PhfZuKNpCcONLktiKZ12UKeSBhVic5/7Pzq4PE 4AwkcKN1UPUm7Br3x9l7i4Iu97T3Av2o+d1q3xRvIx6oqntxJLSHYvF+O g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAgBVIQNX/5xdJa1TCoM3ummCDwENg?= =?us-ascii?q?XKGDQKBNDgUAQEBAQEBAWUnhEIBAQQ4OgYRCxgJFg8JAwIBAgFFBgEMCAEBiCO?= =?us-ascii?q?/EAEBAQEBAQEBAQEBAQEBAQEBGYYghEqEFYYAAQSYAY4IgWiETYMFhVWPGh4BA?= =?us-ascii?q?UKEAyCIVgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,442,1454976000"; d="scan'208";a="257504062" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Apr 2016 02:23:18 +0000 Received: from [10.86.250.161] (bxb-vpn3-673.cisco.com [10.86.250.161]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u352NEgs024577; Tue, 5 Apr 2016 02:23:16 GMT To: Christian Groves , mmusic@ietf.org References: <56E1C193.1050308@alum.mit.edu> <56E2EF31.2020808@alcatel-lucent.com> <56E2F67D.7060005@alum.mit.edu> <56EE0AA1.3030502@nteczone.com> <56EEE286.5090505@alum.mit.edu> <56F09E03.5020200@nteczone.com> <56F198C9.3080604@cisco.com> <56F311CA.4090606@alum.mit.edu> <56FA126E.30003@nteczone.com> From: Flemming Andreasen Message-ID: <57032191.5050502@cisco.com> Date: Mon, 4 Apr 2016 22:23:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56FA126E.30003@nteczone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] IANA registration of SDP attributes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 02:23:28 -0000 On 3/29/16 1:28 AM, Christian Groves wrote: > Hello Paul, > > Please see below. > > Regards, Christian > > On 24/03/2016 8:59 AM, Paul Kyzivat wrote: >> On 3/22/16 3:11 PM, Flemming Andreasen wrote: > >> >> The other thing, that this thread has been discussing, is that this >> only covers definitions of new attributes. >> >> What it doesn't cover are *new* usages of existing attributes. What >> isn't covered are cases that *revise* the definition of an existing >> attribute. For instance, the IANA registry entries for the 'setup' >> and 'connection' attributes only reference RFC4145. (For use with >> TCP.) But these attributes are also used in contexts (with proto >> values) not covered by that RFC. For instance, RFC4572 defines a new >> proto TCP/TLS, and reuses 'setup' and 'connection'. The semantics are >> mostly the same, but additional behavior triggered by these is added >> on. Perhaps the registry entries for these attributes should also >> reference this RFC. In principle, in cases where it matters this >> behavior can be discovered by looking up the references for the >> TCP/TLS proto. But if you are particularly interested in what the >> setup attribute is doing then it might not occur to you to look there. >> >> In that case, the relationship to the original definition is pretty >> clear, since it is still TLS over TCP. It is less clear when used >> with a protocol entirely distinct from TCP. For instance we have >> active drafts draft-ietf-mmusic-sctp-sdp and >> draft-ietf-mmusic-dtls-sdp. These both reuse 'setup', and sctp-sdp >> reuses 'connection', while dtls-sdp has chosen an alternative to >> 'connection'. They also layer on additional behavior. And dtls-sdp >> also forbids use of some of the values defined in 4145 for setup. >> >> IMO it would be good if the registry for 'setup' referenced all of >> these, and that for 'connection' referenced these with the exception >> of dtls-sdp that doesn't use it. This is because these are extending >> the semantics of the attributes. > [CNG] This is the big issue. It will mean an effort to bring the > registry up to the current state and more effort to ensure that it > remains current. It probably comes down to whether people see the > registry as a simple tool to register unique names or something more. There is a difference between revising and extending usage. For extensions, we normally put a sub-registry and a set of associated extension procedures in place. Now, in the case of RFC4145, I don't believe it was envisioned to go beyond TCP originally, and hence extension procedures weren't actually defined at the time. Other protocol uses where later found to be able to use it as well, but again without any formal registry structure to make that clear. Do we have more examples like this or was this a special case (with relatively old origins) ? >> >> But it seems less critical as long as these other documents are >> otherwise discoverable from actual uses. (Such as checking the >> references for the proto value in the m-line associated with these >> uses.) > [CNG] Yes >> >> But IMO it would be essential if the syntax of the attribute is revised. >> >> As you can see, I am a bit ambivalent on this. That is why I think it >> needs discussion. > [CNG] Agree If you change either the syntax or semantic of the attribute, then by definition you have changed it and the reference would need to be updated. If the attribute includes an extension mechanism, then as part of its definition, it needs to include instructions for how to do so, including IANA registration procedures (typically a sub-registry). Normally, this is easy to identify because extensions tend to involve new values and/or parameters of some sort (something syntactical). When the extension is merely semantic (e.g. applying it in a context it was not envisioned originally, like TLS rather than TCP), then it's less clear, because the attribute in question may not have considered that when it was defined originally and hence a formal extension mechanism and registration procedures do not exist. In such a case, I do think it's desirable to have the registry updated to include this new semantic - it makes it easiser to find what they are looking for (or should be looking for). Thanks -- Flemming From nobody Mon Apr 4 19:29:01 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E9712D093 for ; Mon, 4 Apr 2016 19:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 OTAiJN__iizB for ; Mon, 4 Apr 2016 19:28:58 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68C812D0F0 for ; Mon, 4 Apr 2016 19:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2471; q=dns/txt; s=iport; t=1459823338; x=1461032938; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=GwBQu9/D/PRmzpNSBvGDjqjReVvLzo0dSfOx+/UDHbU=; b=Mcx05HUpIzCwbxpYEgY/4pkNfjcoHFbdvJmLnqd/auTTbZOpB5WGQpdA imcnRgNhLeAC9y8iulwSto1xaAopwmZVgA1Q0HqI1PGZnfIPxfGrxlmK+ nt8HHzRG2hbp3CkTol4wu+0kv+ofNlq68Mcb2oOGZjmYMQpnyBjoqGf1E 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAgDHIgNX/4YNJK1dDoMpummCDwENg?= =?us-ascii?q?XKGDQKBNDgUAQEBAQEBAWUnhEEBAQEDATgzBwYGCwsOCgkWDwkDAgECAUUGAQw?= =?us-ascii?q?IAQGIGwi/DgEBAQEBAQEBAQEBAQEBAQEahiCESooVAQSYAYtRgjeBaBeENoMFh?= =?us-ascii?q?VWGGokAHgEBQoMsVyCIVgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,442,1454976000"; d="scan'208";a="257579311" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Apr 2016 02:28:35 +0000 Received: from [10.86.250.161] (bxb-vpn3-673.cisco.com [10.86.250.161]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u352SXR9002556; Tue, 5 Apr 2016 02:28:34 GMT To: Paul Kyzivat , mmusic@ietf.org References: <56E1C193.1050308@alum.mit.edu> <56E2EF31.2020808@alcatel-lucent.com> <56E2F67D.7060005@alum.mit.edu> <56EE0AA1.3030502@nteczone.com> <56EEE286.5090505@alum.mit.edu> <56F09E03.5020200@nteczone.com> <56F198C9.3080604@cisco.com> <56F311CA.4090606@alum.mit.edu> <56FA126E.30003@nteczone.com> <56FABFF0.6060809@alum.mit.edu> From: Flemming Andreasen Message-ID: <570322D0.2080502@cisco.com> Date: Mon, 4 Apr 2016 22:28:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56FABFF0.6060809@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] IANA registration of SDP attributes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 02:29:00 -0000 On 3/29/16 1:48 PM, Paul Kyzivat wrote: > On 3/29/16 1:28 AM, Christian Groves wrote: >> Hello Paul, >> >> Please see below. >> >> Regards, Christian >> >> On 24/03/2016 8:59 AM, Paul Kyzivat wrote: >>> On 3/22/16 3:11 PM, Flemming Andreasen wrote: >>> >>>> Do we have a volunteer to drive the discussion there ? >>> >>> OK. I'll volunteer. >>> >>> The starting point for this discussion is the current text of section >>> 8.2.4 of rfc4566bis-16. >>> >>> Looking at that, one thing leaps out at me: >>> >>> There is a long list of "stuff" that must be provided when defining a >>> new attribute. IMO it is all *good* stuff, that should be provided. >>> But it also strikes me that it will be difficult for IANA to evaluate >>> the adequacy of this stuff itself. So we might want to require an >>> expert review as a gate to registration. >> [CNG] What's the role of the SDP directorate in relation to this? I >> guess they would check any RFC defined attributes but that non-RFCs >> would also need to be checked? How much of this should be visible on the >> IANA registry page? > > The SDP directorate will only be invoked for ietf documents. The > policy for attributes is Specification Required, so it might be a > document from another SDO, ore even no SDO. In those cases there would > be no SDP directorate review. > > After refreshing my memory about the definition of Specification > Required, I see that it implies Expert Review. (Flemming is currently > listed as the expert.) Right - I'm currently the designated expert and hence review all external registration requests (i.e. from outside IETF). > That may be good enough, though we might want to beef up the > requirements in section 8.2.4 of 4566bis. > > The hard part is seeing to any new actions when *existing* attributes > are used in new ways. For that I think the SDP Directorate is all we > have to check for that sort of thing. I wonder if there ought to be a > checklist of things for SDP Directorate reviews. > There probably should, but it shouldn't be any different than for any other SDP extension (syntactic and/or semantic) and hence we should have that in 4566bis. > And of course *that* also will only work for IETF documents. If > somebody outside the IETF defines a new use for an existing attribute > then we have no mechanism to notice that and trigger an update to the > registry. > True -- Flemming From nobody Mon Apr 4 20:08:12 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A3E12D5A0 for ; Mon, 4 Apr 2016 08:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=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 iWYOxgz1p3pk for ; Mon, 4 Apr 2016 08:39:09 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BA0712D591 for ; Mon, 4 Apr 2016 08:39:09 -0700 (PDT) Received: (qmail 54293 invoked from network); 4 Apr 2016 15:39:07 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 9605 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 4 Apr 2016 15:39:07 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id 0884D18A05A7; Mon, 4 Apr 2016 16:39:04 +0100 (BST) Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id EE56C18A06CD; Mon, 4 Apr 2016 16:39:03 +0100 (BST) Received: from [192.67.4.155] (unknown [192.67.4.155]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id C66F018A05A7; Mon, 4 Apr 2016 16:39:03 +0100 (BST) Content-Type: multipart/alternative; boundary="Apple-Mail=_C9F1BDF5-1050-464A-9585-99CC41E96A78" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: pfh In-Reply-To: Date: Mon, 4 Apr 2016 16:39:03 +0100 Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.3124) Archived-At: X-Mailman-Approved-At: Mon, 04 Apr 2016 20:08:11 -0700 Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 15:39:16 -0000 --Apple-Mail=_C9F1BDF5-1050-464A-9585-99CC41E96A78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 4 Apr 2016, at 14:10, Eric Rescorla wrote: >=20 > Hi folks, >=20 > I wanted to call your attention to a draft I just published with a = possibly stupid > idea. >=20 > https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 = >=20 > A nontrivial fraction of call setup time in WebRTC is the DTLS = handshake. > This document describes how to piggyback the first few handshake = messages > in the SDP offer/answer exchange, thus reducing latency. It strikes me we could get the same reduced latency benefits by = piggybacking on ICE rather than SDP, e.g. embedding the DTLS packet as data in a new STUN = attribute type. The downside of piggybacking on the SDP is that you are increasing the = trust you have to place in the signalling server undermining the elegant decoupling we have at the = moment between signalling and=20 media. (The SDES issues of logging keys in the web servers apply to the = public certs as well). It also significantly clutters the SDP (even more) ! As you point out, it weakens the usefulness of longer term certs, which would be a major nuisance IMHO. Tim. --Apple-Mail=_C9F1BDF5-1050-464A-9585-99CC41E96A78 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 4 Apr 2016, at 14:10, Eric Rescorla <ekr@rtfm.com> = wrote:

Hi folks,

I wanted to call your attention to a draft I just published = with a possibly stupid
idea.
https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00

A = nontrivial fraction of call setup time in WebRTC is the DTLS = handshake.
This document describes how to piggyback = the first few handshake messages
in the SDP = offer/answer exchange, thus reducing = latency.

It = strikes me we could get the same reduced latency benefits by = piggybacking on ICE
rather than SDP, e.g. embedding the DTLS = packet as data in a new STUN attribute type.

The downside of piggybacking on the SDP is that = you are increasing the trust you have to place in = the
signalling server undermining the elegant decoupling we = have at the moment between signalling and 
media. (The = SDES issues of logging keys in the web servers apply to the public certs = as well).

It also significantly = clutters the SDP (even more) !

As = you point out, it weakens the usefulness of longer term certs, = which
would be a major nuisance IMHO.

Tim.

= --Apple-Mail=_C9F1BDF5-1050-464A-9585-99CC41E96A78-- From nobody Mon Apr 4 20:41:47 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB5612D0FD; Mon, 4 Apr 2016 20:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=unavailable autolearn_force=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 tTC7yeCSWQUQ; Mon, 4 Apr 2016 20:41:43 -0700 (PDT) Received: from mail.eeph.com (mail.eeph.com [192.135.198.155]) by ietfa.amsl.com (Postfix) with ESMTP id 31EAB12D648; Mon, 4 Apr 2016 20:34:42 -0700 (PDT) Received: from [10.10.155.209] (unknown [10.10.155.209]) (Authenticated sender: matthew@eeph.com) by mail.eeph.com (Postfix) with ESMTPSA id 185DE5C73E8; Mon, 4 Apr 2016 20:34:42 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-3EBB4CF7-A937-4D7B-B1B4-9F27D17AEBAA Mime-Version: 1.0 (1.0) From: Matthew Kaufman X-Mailer: iPhone Mail (13E234) In-Reply-To: Date: Mon, 4 Apr 2016 20:34:41 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: pfh Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 03:41:44 -0000 --Apple-Mail-3EBB4CF7-A937-4D7B-B1B4-9F27D17AEBAA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable As someone who designed a protocol that overlaps NAT traversal / consent and= key agreement, I agree that putting it in the ICE exchange would be benefic= ial. Matthew Kaufman (Sent from my iPhone) > On Apr 4, 2016, at 8:39 AM, pfh wrote: >=20 >=20 >> On 4 Apr 2016, at 14:10, Eric Rescorla wrote: >>=20 >> Hi folks, >>=20 >> I wanted to call your attention to a draft I just published with a possib= ly stupid >> idea. >>=20 >> https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 >>=20 >> A nontrivial fraction of call setup time in WebRTC is the DTLS handshake.= >> This document describes how to piggyback the first few handshake messages= >> in the SDP offer/answer exchange, thus reducing latency. >=20 > It strikes me we could get the same reduced latency benefits by piggybacki= ng on ICE > rather than SDP, e.g. embedding the DTLS packet as data in a new STUN attr= ibute type. >=20 > The downside of piggybacking on the SDP is that you are increasing the tru= st you have to place in the > signalling server undermining the elegant decoupling we have at the moment= between signalling and=20 > media. (The SDES issues of logging keys in the web servers apply to the pu= blic certs as well). >=20 > It also significantly clutters the SDP (even more) ! >=20 > As you point out, it weakens the usefulness of longer term certs, which > would be a major nuisance IMHO. >=20 > Tim. >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --Apple-Mail-3EBB4CF7-A937-4D7B-B1B4-9F27D17AEBAA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
As someone who designed a protocol tha= t overlaps NAT traversal / consent and key agreement, I agree that putting i= t in the ICE exchange would be beneficial.

Matthew Kaufman

(S= ent from my iPhone)

On Apr 4, 2016, at 8:39 AM, pfh <= tim@phonefromhere.com> wrote= :


On 4 Apr 2016, at 14:10, Eric Resc= orla <ekr@rtfm.com> wro= te:

Hi folks,

I wanted to call your attention to a draft I just published with a possib= ly stupid
idea.

https://tools.ietf.org/html/draft-rescorla-dtls-in-s= dp-00

A nontrivial fraction of call setup time in WebRTC is the DTLS handsh= ake.
This document describes how to piggyback the first= few handshake messages
in the SDP offer/answer exchang= e, thus reducing latency.

=
It strikes me we could get the same reduced latency benefits by p= iggybacking on ICE
rather than SDP, e.g. embedding the DTLS packet= as data in a new STUN attribute type.

T= he downside of piggybacking on the SDP is that you are increasing the trust y= ou have to place in the
signalling server undermining the elegant d= ecoupling we have at the moment between signalling and 
media= . (The SDES issues of logging keys in the web servers apply to the public ce= rts as well).

It also significantly clut= ters the SDP (even more) !

As you point o= ut, it weakens the usefulness of longer term certs, which
would be= a major nuisance IMHO.

Tim.
=
_____= __________________________________________
mmusic mailing li= st
mmusic@ietf.org
https= ://www.ietf.org/mailman/listinfo/mmusic
= --Apple-Mail-3EBB4CF7-A937-4D7B-B1B4-9F27D17AEBAA-- From nobody Tue Apr 5 02:52:15 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9252212D140 for ; Tue, 5 Apr 2016 02:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 HclHXoXCLIGx for ; Tue, 5 Apr 2016 02:52:12 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127EA12D10B for ; Tue, 5 Apr 2016 02:52:11 -0700 (PDT) Received: (qmail 54324 invoked from network); 5 Apr 2016 09:52:10 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 3177 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 5 Apr 2016 09:52:10 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id 014B418A00F5; Tue, 5 Apr 2016 10:52:10 +0100 (BST) Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id E464A18A0727; Tue, 5 Apr 2016 10:52:09 +0100 (BST) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id BE15518A00F5; Tue, 5 Apr 2016 10:52:09 +0100 (BST) Content-Type: multipart/alternative; boundary="Apple-Mail=_73971B90-CF02-43F3-83D4-3475486FCF6D" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tim Panton In-Reply-To: Date: Tue, 5 Apr 2016 10:52:09 +0100 Message-Id: References: To: Justin Uberti X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 09:52:14 -0000 --Apple-Mail=_73971B90-CF02-43F3-83D4-3475486FCF6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 5 Apr 2016, at 03:06, Justin Uberti wrote: >=20 >=20 >=20 > On Mon, Apr 4, 2016 at 8:39 AM, pfh > wrote: >=20 >> On 4 Apr 2016, at 14:10, Eric Rescorla > wrote: >>=20 >> Hi folks, >>=20 >> I wanted to call your attention to a draft I just published with a = possibly stupid >> idea. >>=20 >> https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 = >>=20 >> A nontrivial fraction of call setup time in WebRTC is the DTLS = handshake. >> This document describes how to piggyback the first few handshake = messages >> in the SDP offer/answer exchange, thus reducing latency. >=20 > It strikes me we could get the same reduced latency benefits by = piggybacking on ICE > rather than SDP, e.g. embedding the DTLS packet as data in a new STUN = attribute type. >=20 > The downside of piggybacking on the SDP is that you are increasing the = trust you have to place in the > signalling server undermining the elegant decoupling we have at the = moment between signalling and=20 > media. (The SDES issues of logging keys in the web servers apply to = the public certs as well). >=20 > I don't think the logging issue applies here. Only the public key = would be logged, and it's already transmitted in cleartext during a = normal DTLS handshake (it's a public key, after all).=20 True, but over a different path.=20 >=20 > It also significantly clutters the SDP (even more) ! >=20 > Please see Jonathan Lennox's comment about garbage piles. I think the = only truly unattractive part here is the fact that the messages will = need to be base64ed, resulting in minor blowup. But that seems like a = reasonable downside for 1+ RTT upside. Just when the WebRTC NG was freeing us from Offer/Answer and SDP=E2=80=A6.= Sigh. >=20 >=20 > As you point out, it weakens the usefulness of longer term certs, = which > would be a major nuisance IMHO. >=20 > Tim. >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = >=20 >=20 --Apple-Mail=_73971B90-CF02-43F3-83D4-3475486FCF6D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 5 Apr 2016, at 03:06, Justin Uberti <juberti@google.com> = wrote:



On Mon, Apr 4, 2016 at 8:39 AM, = pfh <tim@phonefromhere.com> wrote:

On 4 Apr 2016, at 14:10, Eric Rescorla <ekr@rtfm.com> wrote:

Hi folks,

I wanted to call your attention to a = draft I just published with a possibly stupid
idea.

https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00

A = nontrivial fraction of call setup time in WebRTC is the DTLS = handshake.
This document describes how to piggyback = the first few handshake messages
in the SDP = offer/answer exchange, thus reducing = latency.

It strikes me we could get the = same reduced latency benefits by piggybacking on ICE
rather than SDP, e.g. embedding the DTLS packet as data in a = new STUN attribute type.

The downside of piggybacking on the SDP is that you are = increasing the trust you have to place in the
signalling server undermining the elegant decoupling we have = at the moment between signalling and 
media. = (The SDES issues of logging keys in the web servers apply to the public = certs as well).

I don't think the logging issue applies = here. Only the public key would be logged, and it's already transmitted = in cleartext during a normal DTLS handshake (it's a public key, after = all). 

True, but over a different path. 


It also significantly = clutters the SDP (even more) !

Please see Jonathan = Lennox's comment about garbage piles. I think the only truly = unattractive part here is the fact that the messages will need to be = base64ed, resulting in minor blowup. But that seems like a reasonable = downside for 1+ RTT = upside.

Just when the WebRTC NG was freeing us from = Offer/Answer and SDP=E2=80=A6.

Sigh.




As you point out, it weakens the usefulness of longer term = certs, which
would be a major nuisance = IMHO.

Tim.


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
=


= --Apple-Mail=_73971B90-CF02-43F3-83D4-3475486FCF6D-- From nobody Tue Apr 5 02:58:33 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C3712D0B9 for ; Tue, 5 Apr 2016 02:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable autolearn_force=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 Cvj4NedsnRGz for ; Tue, 5 Apr 2016 02:58:27 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFF4A12D1A6 for ; Tue, 5 Apr 2016 02:58:26 -0700 (PDT) Received: (qmail 62245 invoked from network); 5 Apr 2016 09:58:25 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 3303 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 5 Apr 2016 09:58:25 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id EFE1018A0666; Tue, 5 Apr 2016 10:58:24 +0100 (BST) Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id E281218A046D; Tue, 5 Apr 2016 10:58:24 +0100 (BST) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id C528218A046C; Tue, 5 Apr 2016 10:58:24 +0100 (BST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tim Panton In-Reply-To: Date: Tue, 5 Apr 2016 10:58:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <82A90D4E-4793-4A21-BB7D-CE3594D55AF6@phonefromhere.com> References: To: Martin Thomson X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 09:58:29 -0000 > On 4 Apr 2016, at 18:34, Martin Thomson = wrote: >=20 > On 4 April 2016 at 12:39, pfh wrote: >> It strikes me we could get the same reduced latency benefits by = piggybacking >> on ICE >> rather than SDP, e.g. embedding the DTLS packet as data in a new STUN >> attribute type. >=20 > One of the goals for connectivity checks is to keep them small. > Cramming DTLS in is not compatible with this. It wouldn=E2=80=99t be in every ICE packet, just in ones with (say) = USE-CANDIDATE set. T. From nobody Tue Apr 5 06:07:35 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF0512D6B7; Tue, 5 Apr 2016 06:07:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160405130733.25830.49945.idtracker@ietfa.amsl.com> Date: Tue, 05 Apr 2016 06:07:33 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-msid-13.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 13:07:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : WebRTC MediaStream Identification in the Session Description Protocol Author : Harald Alvestrand Filename : draft-ietf-mmusic-msid-13.txt Pages : 16 Date : 2016-04-05 Abstract: This document specifies a Session Description Protocol (SDP) Grouping mechanism for RTP media streams that can be used to specify relations between media streams. This mechanism is used to signal the association between the SDP concept of "media description" and the WebRTC concept of "MediaStream" / "MediaStreamTrack" using SDP signaling. This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-msid-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 5 07:15:00 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD6612D5F2 for ; Tue, 5 Apr 2016 07:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 7J9QbffCaW5u for ; Tue, 5 Apr 2016 07:14:56 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0034A12D5ED for ; Tue, 5 Apr 2016 07:14:55 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id f198so34114460wme.0 for ; Tue, 05 Apr 2016 07:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=HTelZfytmM5kNTEJeTGHtZCyqI2+khP43nThOibwR6U=; b=JU4Xpvw1TsnrlVgq1LL2226Liirmi5W26Jl0owOV+1+frQUpfflwy1NcNLhTH2d13z HOxnszx76Ty2eLjB6bZdsIhKNDu8r4/tuSKEFPmJQKH0hvdwobB8tieTIvPetuve1Uif hpi1hhzGFWA830DotXZBMv6ts+3FOhY417vHBIEqyB6UHmisUHA+dr3aUeKsT/fysPzm qJCFHiHftj1jUvxSLXRt/ar0mpQCZQsfkqR36FodJVGBZBYqP+cDzO52IwqeBT4GrnOI l6ogxT0JvGsyKCSlsum0oCHXO1wqJ0KMPGEF0xNE/RIIu4x0C173tcBGiiWTviHaiCfo lc0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=HTelZfytmM5kNTEJeTGHtZCyqI2+khP43nThOibwR6U=; b=HcdcyplFX6Vp/ec6ngAKwrARwHcFiw/U+XazN/aTNnO8hbdskvQfmAv1a6RDSBEAw7 bMxareggrThRRAIzY2T3BtPYgFDzbjowFtMD+80WEr+xSLFF2Kl6668gLqbAMWj2Vbkn fu5NK8mMVsusM/jSTM4sIgzYBUJgUWs76O6XBDc1eAa7N2uEJZlIcdejqWMZVt7tQTa6 xh68W/9o1OTuhSQkYpLwNMqdGwaStllenAIDRmY/gzEP9+hf51+ErgMdArwl4Kw53Vf6 0EzDwaLLzvTSr9dTS6oXw1MRl6f92dVmdHYsZGkVb/jKm7eX/Fme8/45+dEFEbcz0NMZ 4iFQ== X-Gm-Message-State: AD7BkJIx9+3dwF9Yp8Hc5FNA6kC+ZW/9vINjxlJ1kg7RHaYN/mNQ7rE2oQPleLqIB1x3i0zZl0f0Wa4vmOFb4B9o X-Received: by 10.194.6.36 with SMTP id x4mr16399177wjx.122.1459865694337; Tue, 05 Apr 2016 07:14:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.148.79 with HTTP; Tue, 5 Apr 2016 07:14:34 -0700 (PDT) From: Justin Uberti Date: Tue, 5 Apr 2016 07:14:34 -0700 Message-ID: To: "mmusic@ietf.org" Content-Type: multipart/mixed; boundary=047d7b5d295c2292a0052fbd781c Archived-At: Subject: [MMUSIC] a=rtcp-mux-exclusive vs a=rtcp:0 compression X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 14:14:58 -0000 --047d7b5d295c2292a0052fbd781c Content-Type: multipart/alternative; boundary=047d7b5d295c22929b052fbd781a --047d7b5d295c22929b052fbd781a Content-Type: text/plain; charset=UTF-8 Minor point for the beauty contest... Compressing the attached SDP files (adapted from the examples in https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-14#section-7.1) with gzip (default settings) gives the following output: | port 0 | -exclusive | ------------------------------------- Uncompressed | 1467 | 1487 | Compressed | 723 | 739 | --047d7b5d295c22929b052fbd781a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Minor point for the beauty contest...

C= ompressing the attached SDP files (adapted from the examples in https://= tools.ietf.org/html/draft-ietf-rtcweb-jsep-14#section-7.1) with gzip (d= efault settings) gives the following output:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | port 0 | -exclusive |
-------------------------------------
Uncompressed =C2=A0| =C2=A0 14= 67 | =C2=A0 =C2=A0 =C2=A0 1487 |
Compressed =C2=A0 =C2=A0| =C2=A0 =C2=A0723 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0739 |


--047d7b5d295c22929b052fbd781a-- --047d7b5d295c2292a0052fbd781c Content-Type: application/vnd.sun.xml.impress; name="example71-offer-exclusive.sdp" Content-Disposition: attachment; filename="example71-offer-exclusive.sdp" Content-Transfer-Encoding: base64 X-Attachment-Id: f_imniaze90 dj0wCm89LSA0OTYyMzAzMzMzMTc5ODcxNzIyIDEgSU4gSVA0IDAuMC4wLjAKcz0tCnQ9MCAwCmE9 Z3JvdXA6QlVORExFIGExIHYxCmE9aWNlLW9wdGlvbnM6dHJpY2tsZQptPWF1ZGlvIDkgVURQL1RM Uy9SVFAvU0FWUEYgOTYgMCA4IDk3IDk4CmM9SU4gSVA0IDAuMC4wLjAKYT1taWQ6YTEKYT1ydGNw OjAgSU4gSVA0IDAuMC4wLjAKYT1tc2lkOjQ3MDE3ZmVlLWI2YzEtNDE2Mi05MjljLWEyNTExMDI1 MjQwMCBmODMwMDZjNS1hMGZmLTRlMGEtOWVkOS1kM2U2NzQ3YmU3ZDkKYT1zZW5kcmVjdgphPXJ0 cG1hcDo5NiBvcHVzLzQ4MDAwLzIKYT1ydHBtYXA6MCBQQ01VLzgwMDAKYT1ydHBtYXA6OCBQQ01B LzgwMDAKYT1ydHBtYXA6OTcgdGVsZXBob25lLWV2ZW50LzgwMDAKYT1ydHBtYXA6OTggdGVsZXBo b25lLWV2ZW50LzQ4MDAwCmE9bWF4cHRpbWU6MTIwCmE9aWNlLXVmcmFnOkVURW4KYT1pY2UtcHdk Ok90U0swV3BOdHBVamtZNCs4NmpzN1pRbAphPWZpbmdlcnByaW50OnNoYS0yNTYgMTk6RTI6MUM6 M0I6NEI6OUY6ODE6RTY6Qjg6NUM6RjQ6QTU6QTg6RDg6NzM6MDQ6QkI6MDU6MkY6NzA6OUY6MDQ6 QTk6MEUwNTpFOToyNjozMzpFODo3MDo4ODpBMgphPXNldHVwOmFjdHBhc3MKYT1ydGNwLW11eC1l eGNsdXNpdmUKYT1ydGNwLXJzaXplCmE9ZXh0bWFwOjEgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJl eHQ6c3NyYy1hdWRpby1sZXZlbAphPWV4dG1hcDoyIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0 OnNkZXM6bWlkCmE9c3NyYzoxNzMyODQ2MzgwIGNuYW1lOkVvY1VHMWYwZmNnL3l2WTcKbT12aWRl byA5IFVEUC9UTFMvUlRQL1NBVlBGIDEwMCAxMDEKYz1JTiBJUDQgMC4wLjAuMAphPXJ0Y3A6OSBJ TiBJUDQgMC4wLjAuMAphPW1pZDp2MQphPW1zaWQ6NjEzMTc0ODQtMmVkNC00OWQ3LTllYjctMTQx NDMyMmE3YWFlIGYzMGJkYjRhLTVkYjgtNDliNS1iY2RjLWUwYzlhMjMxNzJlMAphPXNlbmRyZWN2 CmE9cnRwbWFwOjEwMCBWUDgvOTAwMDAKYT1ydHBtYXA6MTAxIHJ0eC85MDAwMAphPWZtdHA6MTAx IGFwdD0xMDAKYT1pY2UtdWZyYWc6QkdLawphPWljZS1wd2Q6bXF5V3NBanZ0S3dUR252aFB6dFE5 bUlmCmE9ZmluZ2VycHJpbnQ6c2hhLTI1NiAxOTpFMjoxQzozQjo0Qjo5Rjo4MTpFNjpCODo1QzpG NDpBNTpBODpEODo3MzowNDpCQjowNToyRjo3MDo5RjowNDpBOTowRTowNTpFOToyNjozMzpFODo3 MDo4ODpBMgphPXNldHVwOmFjdHBhc3MKYT1ydGNwLW11eC1leGNsdXNpdmUKYT1ydGNwLXJzaXpl CmE9ZXh0bWFwOjMgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c2RlczptaWQKYT1ydGNwLWZi OjEwMCBjY20gZmlyCmE9cnRjcC1mYjoxMDAgbmFjawphPXJ0Y3AtZmI6MTAwIG5hY2sgcGxpCmE9 c3NyYzoxMzY2NzgxMDgzIGNuYW1lOkVvY1VHMWYwZmNnL3l2WTcKYT1zc3JjOjEzNjY3ODEwODQg Y25hbWU6RW9jVUcxZjBmY2cveXZZNwphPXNzcmMtZ3JvdXA6RklEIDEzNjY3ODEwODMgMTM2Njc4 MTA4NAo= --047d7b5d295c2292a0052fbd781c Content-Type: application/vnd.sun.xml.impress; name="example71-offer-0.sdp" Content-Disposition: attachment; filename="example71-offer-0.sdp" Content-Transfer-Encoding: base64 X-Attachment-Id: f_imniazel1 dj0wCm89LSA0OTYyMzAzMzMzMTc5ODcxNzIyIDEgSU4gSVA0IDAuMC4wLjAKcz0tCnQ9MCAwCmE9 Z3JvdXA6QlVORExFIGExIHYxCmE9aWNlLW9wdGlvbnM6dHJpY2tsZQptPWF1ZGlvIDkgVURQL1RM Uy9SVFAvU0FWUEYgOTYgMCA4IDk3IDk4CmM9SU4gSVA0IDAuMC4wLjAKYT1taWQ6YTEKYT1ydGNw OjAgSU4gSVA0IDAuMC4wLjAKYT1tc2lkOjQ3MDE3ZmVlLWI2YzEtNDE2Mi05MjljLWEyNTExMDI1 MjQwMCBmODMwMDZjNS1hMGZmLTRlMGEtOWVkOS1kM2U2NzQ3YmU3ZDkKYT1zZW5kcmVjdgphPXJ0 cG1hcDo5NiBvcHVzLzQ4MDAwLzIKYT1ydHBtYXA6MCBQQ01VLzgwMDAKYT1ydHBtYXA6OCBQQ01B LzgwMDAKYT1ydHBtYXA6OTcgdGVsZXBob25lLWV2ZW50LzgwMDAKYT1ydHBtYXA6OTggdGVsZXBo b25lLWV2ZW50LzQ4MDAwCmE9bWF4cHRpbWU6MTIwCmE9aWNlLXVmcmFnOkVURW4KYT1pY2UtcHdk Ok90U0swV3BOdHBVamtZNCs4NmpzN1pRbAphPWZpbmdlcnByaW50OnNoYS0yNTYgMTk6RTI6MUM6 M0I6NEI6OUY6ODE6RTY6Qjg6NUM6RjQ6QTU6QTg6RDg6NzM6MDQ6QkI6MDU6MkY6NzA6OUY6MDQ6 QTk6MEUwNTpFOToyNjozMzpFODo3MDo4ODpBMgphPXNldHVwOmFjdHBhc3MKYT1ydGNwLW11eAph PXJ0Y3AtcnNpemUKYT1leHRtYXA6MSB1cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzc3JjLWF1 ZGlvLWxldmVsCmE9ZXh0bWFwOjIgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c2RlczptaWQK YT1zc3JjOjE3MzI4NDYzODAgY25hbWU6RW9jVUcxZjBmY2cveXZZNwptPXZpZGVvIDkgVURQL1RM Uy9SVFAvU0FWUEYgMTAwIDEwMQpjPUlOIElQNCAwLjAuMC4wCmE9cnRjcDowIElOIElQNCAwLjAu MC4wCmE9bWlkOnYxCmE9bXNpZDo2MTMxNzQ4NC0yZWQ0LTQ5ZDctOWViNy0xNDE0MzIyYTdhYWUg ZjMwYmRiNGEtNWRiOC00OWI1LWJjZGMtZTBjOWEyMzE3MmUwCmE9c2VuZHJlY3YKYT1ydHBtYXA6 MTAwIFZQOC85MDAwMAphPXJ0cG1hcDoxMDEgcnR4LzkwMDAwCmE9Zm10cDoxMDEgYXB0PTEwMAph PWljZS11ZnJhZzpCR0trCmE9aWNlLXB3ZDptcXlXc0FqdnRLd1RHbnZoUHp0UTltSWYKYT1maW5n ZXJwcmludDpzaGEtMjU2IDE5OkUyOjFDOjNCOjRCOjlGOjgxOkU2OkI4OjVDOkY0OkE1OkE4OkQ4 OjczOjA0OkJCOjA1OjJGOjcwOjlGOjA0OkE5OjBFOjA1OkU5OjI2OjMzOkU4OjcwOjg4OkEyCmE9 c2V0dXA6YWN0cGFzcwphPXJ0Y3AtbXV4CmE9cnRjcC1yc2l6ZQphPWV4dG1hcDozIHVybjppZXRm OnBhcmFtczpydHAtaGRyZXh0OnNkZXM6bWlkCmE9cnRjcC1mYjoxMDAgY2NtIGZpcgphPXJ0Y3At ZmI6MTAwIG5hY2sKYT1ydGNwLWZiOjEwMCBuYWNrIHBsaQphPXNzcmM6MTM2Njc4MTA4MyBjbmFt ZTpFb2NVRzFmMGZjZy95dlk3CmE9c3NyYzoxMzY2NzgxMDg0IGNuYW1lOkVvY1VHMWYwZmNnL3l2 WTcKYT1zc3JjLWdyb3VwOkZJRCAxMzY2NzgxMDgzIDEzNjY3ODEwODQK --047d7b5d295c2292a0052fbd781c-- From nobody Tue Apr 5 07:15:23 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0210512D542 for ; Tue, 5 Apr 2016 07:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 MrDBLlXAv6Qz for ; Tue, 5 Apr 2016 07:15:20 -0700 (PDT) Received: from smtp122.ord1c.emailsrvr.com (smtp122.ord1c.emailsrvr.com [108.166.43.122]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B142012D535 for ; Tue, 5 Apr 2016 07:15:20 -0700 (PDT) Received: from smtp8.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp8.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 107DA8050F; Tue, 5 Apr 2016 10:15:20 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp8.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 3323E804F9; Tue, 5 Apr 2016 10:15:18 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.66.110] ([UNAVAILABLE]. [128.107.241.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Tue, 05 Apr 2016 10:15:20 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E411AC@ESESSMB209.ericsson.se> Date: Tue, 5 Apr 2016 11:15:17 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B37E411AC@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Aligning RFC 4572 and draft-dtls-sdp regarding preferred SHA cipher? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 14:15:23 -0000 I agree we need multiple hashes. I think the device checking the = fingerprints should through out hashes that use an algorithm it does not = trust, then make sure *one* of the remaining hash matches. There were use cases discussed in meeting on why.=20 From nobody Tue Apr 5 07:38:53 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF1212D0ED for ; Tue, 5 Apr 2016 07:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 FQzsEU2ik6OJ for ; Tue, 5 Apr 2016 07:38:49 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1284E12D0BA for ; Tue, 5 Apr 2016 07:38:49 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 0491961DB0C37 for ; Tue, 5 Apr 2016 14:38:45 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u35Ecl7o019069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 5 Apr 2016 14:38:47 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u35Eckil008104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 5 Apr 2016 16:38:46 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.185]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 5 Apr 2016 16:38:46 +0200 From: "Drage, Keith (Nokia - GB)" To: "mmusic@ietf.org" Thread-Topic: IANA registry structure for IANA attributes Thread-Index: AdGPSJD+Iat0mrlPTP6P2AK2ugo7kw== Date: Tue, 5 Apr 2016 14:38:45 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADEB9F2E@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [MMUSIC] IANA registry structure for IANA attributes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 14:38:52 -0000 Firstly I agree with Cullen that if any RFC updates the semantics of an exi= sting attribute (i.e. makes normative changes to it) then that RFC formally= needs to update the prior RFC. The registry should allow multiple references to RFCs where those RFCs make= define additional semantics to an attribute, and MMUSIC should attempt to = revise the attribute registry if these are missing. I think the separation of attributes into multiple subregistries is a bit h= istorical rather than something that is needed. I am not proposing taking i= t away (although conversely would not object if it did provided this inform= ation was normatively clear in the base RFCs), but it goes beyond what is r= equired. I do not think there is anything special about dcsa usage. Most dcsa usage = does not change the semantics of the underlying attributes. Obviously if dc= sa usage does change the semantics of an underlying attribute then the dcsa= usage document should update the reference list. I do not think the msrp d= csa document makes any semantic change to any MSRP attributes - they can ju= st be used. I have a problem with a new DCSA level if it implies that an attribute cann= ot be used within dsca if it does not appear in this list. Regards Keith From nobody Tue Apr 5 07:50:27 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778A712D1A3 for ; Tue, 5 Apr 2016 07:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Dfos_aZHefyX for ; Tue, 5 Apr 2016 07:50:23 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6360212D154 for ; Tue, 5 Apr 2016 07:50:23 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 11326AB3EA2FD for ; Tue, 5 Apr 2016 14:50:19 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u35EoLDu004026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 5 Apr 2016 14:50:21 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u35Eo9NO000349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 5 Apr 2016 16:50:20 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.185]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 5 Apr 2016 16:50:17 +0200 From: "Drage, Keith (Nokia - GB)" To: "Drage, Keith (Nokia - GB)" , "mmusic@ietf.org" Thread-Topic: IANA registry structure for IANA attributes Thread-Index: AdGPSJD+Iat0mrlPTP6P2AK2ugo7kwAAZ1Mg Date: Tue, 5 Apr 2016 14:50:17 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADEB9F73@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8BADEB9F2E@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADEB9F2E@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [MMUSIC] IANA registry structure for IANA attributes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 14:50:25 -0000 I am listening to the discussion as it occurs in the meeting. I do not really agree that dcsa is a something separate and special. In general, anything that can be used at the media level can be used in dcs= a. Mostly any usage will be determined on whether it still makes sense when= used in dcsa. There will generally be nothing to say about dcsa usage over and above that= . I do not want to create some new draft that has to work through all the exi= sting attributes just to formally defined that. Keith -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of EXT Drage, Keith= (Nokia - GB) Sent: 05 April 2016 15:39 To: mmusic@ietf.org Subject: [MMUSIC] IANA registry structure for IANA attributes Firstly I agree with Cullen that if any RFC updates the semantics of an exi= sting attribute (i.e. makes normative changes to it) then that RFC formally= needs to update the prior RFC. The registry should allow multiple references to RFCs where those RFCs make= define additional semantics to an attribute, and MMUSIC should attempt to = revise the attribute registry if these are missing. I think the separation of attributes into multiple subregistries is a bit h= istorical rather than something that is needed. I am not proposing taking i= t away (although conversely would not object if it did provided this inform= ation was normatively clear in the base RFCs), but it goes beyond what is r= equired. I do not think there is anything special about dcsa usage. Most dcsa usage = does not change the semantics of the underlying attributes. Obviously if dc= sa usage does change the semantics of an underlying attribute then the dcsa= usage document should update the reference list. I do not think the msrp d= csa document makes any semantic change to any MSRP attributes - they can ju= st be used. I have a problem with a new DCSA level if it implies that an attribute cann= ot be used within dsca if it does not appear in this list. Regards Keith _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue Apr 5 09:18:24 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831AF12D6CB for ; Tue, 5 Apr 2016 09:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 P9GW_rUELiOH for ; Tue, 5 Apr 2016 09:18:20 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4DBF12D0DA for ; Tue, 5 Apr 2016 09:18:20 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by comcast with SMTP id nTfVayUSUpUrhnTgKaEAcg; Tue, 05 Apr 2016 16:18:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1459873100; bh=0GI7vlD0RA48QUv3uiDiiVTAZDcivEKVt/ebOfXfGFU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=EGICia/szqjyuvhlHhrPjRE1hgxisNiafVfd6TLdEL/DpGur+TMDR5vWPJ0heL1u+ 50Ho9OPPrcTIx4cLiW8+hI+VXqyBSH3x2i0ncj8gVoSRiaZD8XCfaBc0svyoCWlYET NdmXamjpQEbHD+qOXfahhMWYxdCrBaLqvVQotNP/68swY8MD0E1BtZFQKbiTi5qxoA +/mkcjtH2pP8b+krBlAbkvOAfduXub/SXEaLSGB6ZPOEF9RGTuj/6uaNPOGoSmeRO5 cemSnDMYoNdmrKqDJp35AP9WahGnzRpFeOX7a0keVQyyoCBbeOPVl3VIGi93Y89Z4v fsICcxF+xBgcg== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-10v.sys.comcast.net with comcast id egJK1s0083KdFy101gJKXb; Tue, 05 Apr 2016 16:18:19 +0000 To: mmusic@ietf.org References: <949EF20990823C4C85C18D59AA11AD8BADEB9F2E@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Paul Kyzivat Message-ID: <5703E549.1090805@alum.mit.edu> Date: Tue, 5 Apr 2016 12:18:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADEB9F2E@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] IANA registry structure for IANA attributes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 16:18:22 -0000 On 4/5/16 10:38 AM, Drage, Keith (Nokia - GB) wrote: > Firstly I agree with Cullen that if any RFC updates the semantics of an existing attribute (i.e. makes normative changes to it) then that RFC formally needs to update the prior RFC. > > The registry should allow multiple references to RFCs where those RFCs make define additional semantics to an attribute, and MMUSIC should attempt to revise the attribute registry if these are missing. At least we agree on the above. :-) But there is an ongoing debate on what sorts of things should be considered updates. My desire is, given a sample usage of an attribute, to find the document that defines that usage. Preferably, I want to avoid having to read a lot of extraneous documents. > I think the separation of attributes into multiple subregistries is a bit historical rather than something that is needed. It predates my awareness of SDP, so I can only speculate about the thinking that led to it. > I am not proposing taking it away (although conversely would not object if it did provided this information was normatively clear in the base RFCs), but it goes beyond what is required. I *think* this info is available in documents for all the existing attributes, with regard to the session/media-level distinction. And I think (without looking) that specifications for attributes that can be used at source level say so. What *isn't* in existing documents in explicit indication that an attribute is *not* defined for use at source level. I suppose this could be dealt with by having 4566bis specify that any attribute definition that doesn't explicitly specify validity at source level is *not* valid at source level. (Note: there is only *one* attribute (fmtp) that is defined at source level *and* at another level.) > I do not think there is anything special about dcsa usage. Most dcsa usage does not change the semantics of the underlying attributes. Obviously if dcsa usage does change the semantics of an underlying attribute then the dcsa usage document should update the reference list. I do not think the msrp dcsa document makes any semantic change to any MSRP attributes - they can just be used. > > I have a problem with a new DCSA level if it implies that an attribute cannot be used within dsca if it does not appear in this list. Can't the same be said about session/media/source level? In a syntactic sense I can use any attribute at any level. It is just that a lot of them won't be valid in many contexts. Specifically regarding dcsa, it requires a new specification to say how a protocol that runs over UDP or TCP will be mapped onto a data channel. That mapping MAY say that all the attributes that apply on the original transport still apply on the data channel. Or maybe not. And which attributes are meaningful will still depend on which (sub)protocol is being run on that data channel. Of course the same is true for the existing protocols. Not all attributes are meaningful with all m-line proto values. (For instance, many attributes are only meaningful with the RTP family of proto values.) And we don't (currently) put that info into the registry. (Maybe we should.) This isn't a big deal if all the relevant documents can be found (directly or indirectly) from the references in the registry, and there aren't very many of those. If we start to have numerous documents for an attribute, then having *something* in the registry to help choose among them would be helpful. Thanks, Paul > Regards > > Keith > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Tue Apr 5 13:18:24 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13E812D14E for ; Tue, 5 Apr 2016 13:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 2GZlh-a-54y4 for ; Tue, 5 Apr 2016 13:18:20 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB83712D12C for ; Tue, 5 Apr 2016 13:18:20 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 76FB12D44F2FE; Tue, 5 Apr 2016 20:18:15 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u35KIIbt028752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Apr 2016 20:18:18 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u35KIH6X017519 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Apr 2016 22:18:17 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.185]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 5 Apr 2016 22:18:17 +0200 From: "Drage, Keith (Nokia - GB)" To: EXT Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] IANA registry structure for IANA attributes Thread-Index: AdGPSJD+Iat0mrlPTP6P2AK2ugo7k///+t0A//+ovUA= Date: Tue, 5 Apr 2016 20:18:17 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADEBA390@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8BADEB9F2E@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5703E549.1090805@alum.mit.edu> In-Reply-To: <5703E549.1090805@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [MMUSIC] IANA registry structure for IANA attributes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 20:18:23 -0000 Paul said: " But there is an ongoing debate on what sorts of things should be consider= ed updates." My view is it is anything that changes the definition of the attribute, i.e= . something that extends the attribute or makes new general requirements (n= ot just rescoping). Appearance in an example does not count. Paul said: " Can't the same be said about session/media/source level?" My answer is that in my view we are still talking attributes essentially be= ing used at media level. It just happens to relate to a media that is a sub= channel within the datachannel, but it is still media. As such in general t= he attribute usage does not change, and no harm results.=20 So my view is that all attributes that are defined as media attributes can = be dcsa attributes (and we can add the caveat that "unless otherwise specif= ied", but I do not think it will come up very often). Yes that needs to be = written in a specification somewhere. I'd note that some will be also be di= squalified for conditions already specified at source definition, like thos= e any that relate specifically to rtp streams. Keith -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of EXT Paul Kyzivat Sent: 05 April 2016 17:18 To: mmusic@ietf.org Subject: Re: [MMUSIC] IANA registry structure for IANA attributes On 4/5/16 10:38 AM, Drage, Keith (Nokia - GB) wrote: > Firstly I agree with Cullen that if any RFC updates the semantics of an e= xisting attribute (i.e. makes normative changes to it) then that RFC formal= ly needs to update the prior RFC. > > The registry should allow multiple references to RFCs where those RFCs ma= ke define additional semantics to an attribute, and MMUSIC should attempt t= o revise the attribute registry if these are missing. At least we agree on the above. :-) But there is an ongoing debate on what sorts of things should be considered= updates. My desire is, given a sample usage of an attribute, to find the document th= at defines that usage. Preferably, I want to avoid having to read a lot of = extraneous documents. > I think the separation of attributes into multiple subregistries is a bit= historical rather than something that is needed. It predates my awareness of SDP, so I can only speculate about the thinking= that led to it. > I am not proposing taking it away (although conversely would not object i= f it did provided this information was normatively clear in the base RFCs),= but it goes beyond what is required. I *think* this info is available in documents for all the existing attribut= es, with regard to the session/media-level distinction. And I think (without looking) that specifications for attributes that can b= e used at source level say so. What *isn't* in existing documents in explicit indication that an attribute= is *not* defined for use at source level. I suppose this could be dealt with by having 4566bis specify that any attri= bute definition that doesn't explicitly specify validity at source level is= *not* valid at source level. (Note: there is only *one* attribute (fmtp) that is defined at source level= *and* at another level.) > I do not think there is anything special about dcsa usage. Most dcsa usag= e does not change the semantics of the underlying attributes. Obviously if = dcsa usage does change the semantics of an underlying attribute then the dc= sa usage document should update the reference list. I do not think the msrp= dcsa document makes any semantic change to any MSRP attributes - they can = just be used. > > I have a problem with a new DCSA level if it implies that an attribute ca= nnot be used within dsca if it does not appear in this list. Can't the same be said about session/media/source level? In a syntactic sense I can use any attribute at any level. It is just that = a lot of them won't be valid in many contexts. Specifically regarding dcsa, it requires a new specification to say how a p= rotocol that runs over UDP or TCP will be mapped onto a data channel.=20 That mapping MAY say that all the attributes that apply on the original tra= nsport still apply on the data channel. Or maybe not. And which attributes = are meaningful will still depend on which (sub)protocol is being run on tha= t data channel. Of course the same is true for the existing protocols. Not all attributes a= re meaningful with all m-line proto values. (For instance, many attributes = are only meaningful with the RTP family of proto values.) And we don't (currently) put that info into the registry.=20 (Maybe we should.) This isn't a big deal if all the relevant documents can be found (directly = or indirectly) from the references in the registry, and there aren't very m= any of those. If we start to have numerous documents for an attribute, then having *something* in the registry to help choose among them would be helpful. Thanks, Paul > Regards > > Keith > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue Apr 5 14:01:10 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E20B12DA07 for ; Tue, 5 Apr 2016 14:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgNhV8AbqpwW for ; Tue, 5 Apr 2016 14:01:08 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DC8C12DA04 for ; Tue, 5 Apr 2016 14:01:06 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-d0-57042790302b Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 51.4D.22880.09724075; Tue, 5 Apr 2016 23:01:04 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Tue, 5 Apr 2016 23:00:55 +0200 From: Christer Holmberg To: mmusic WG Thread-Topic: IETF#95: Off-line discussion regarding mux-exclusive Thread-Index: AdGPfdlhvkVXxSF1S7aS3dRmcJyW1g== Date: Tue, 5 Apr 2016 21:00:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F24416@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37F24416ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM2K7me4EdZZwg9dLTC2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujD0HTrAXPJKo6N2/n6WB8YtoFyMnh4SAicT3SVNZIGwxiQv3 1rN1MXJxCAkcYZQ4N+UhlLOIUeLRkidADgcHm4CFRPc/bZAGEQF5iY+d5xhBbGEBW4nvpw6z QsSdJHoXNbJA2HoSa1Y9BrNZBFQkrv29B2bzCvhKdJzrA+tlBFr8/dQaJhCbWUBc4taT+UwQ BwlILNlznhnCFpV4+fgfK4StJLH28HYWiPp8id8TlzFBzBSUODnzCcsERqFZSEbNQlI2C0kZ RFxHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8UoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokR GBMHt/zW3cG4+rXjIUYBDkYlHl4FGeZwIdbEsuLK3EOMEhzMSiK8jWos4UK8KYmVValF+fFF pTmpxYcYpTlYlMR5cyL/hQkJpCeWpGanphakFsFkmTg4pRoY8368dW+0ahaWDI7sWn6+m39e 2/T05Hl5C/VS7NVzZTlebGKdGLUs1tHm4AVmxsYPd2bdYCtlEVU8abll38Vo4a5z/s+YNoTs rJpxcLvjzic/5DMvbBeLVVpes/93Dd+FHQvPbzBqulIUWmrjpD3dw/1PAFvRL4G/hs8mX+pb OWnhhW/1TN7iSizFGYmGWsxFxYkAOiuZKoUCAAA= Archived-At: Subject: [MMUSIC] IETF#95: Off-line discussion regarding mux-exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 21:01:09 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37F24416ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've discussed mux-exclusive off-line with the individuals who weren't able= to attend the MMUSIC session today. Based on the WG consensus that we do need an explicit indicator, they indic= ated that they can live with either alternative ('a=3Drtcp-mux-exclusive' o= r 'a=3Drtcp:0'). Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37F24416ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve discussed mux-exclusive off-line with the= individuals who weren’t able to attend the MMUSIC session today.

 

Based on the WG consensus that we do need an explici= t indicator, they indicated that they can live with either alternative (= 216;a=3Drtcp-mux-exclusive’ or ‘a=3Drtcp:0’).

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37F24416ESESSMB209erics_-- From nobody Tue Apr 5 14:24:34 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9AE212DA30 for ; Tue, 5 Apr 2016 14:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 M_Fwh4NJAsFi for ; Tue, 5 Apr 2016 14:24:31 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9B6E12DA2F for ; Tue, 5 Apr 2016 14:24:30 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by comcast with SMTP id nYRUa1Y5sjuYRnYScaTcdJ; Tue, 05 Apr 2016 21:24:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1459891470; bh=pu/S34Epv6iNm4sBdqypkOH5pqXaQI6e9DWZ1Foq6PQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=ZuCyFh2CIlHn61IlIrPB1HDTnZdpSwpKi1/DXnEnQlZkhudoSxS5OoroFN5EUUaZ3 wKIhH9ajBw5Z9Do/Vb+Depr69tTG0jlBZIMX+5ipi4YfrTO3Pz5qdFfJsur+nUFITu EQGuDt68BxFMw1IA+lU3GG53KWZfLPfkFzDA7YV5GzdfwSG8M4BiwMuRz+jqt5dKQ5 wOLbLKAJjsEFKQCICABOINzao1bET//OWJvNNe0zzXOao5wn2tTNtTOtvZv5E7ATzh m1FiGbxU/W09Fm7kkbSMqle4uFJPlp58eYQyiuEKfcplm6Yf+V8Spv6NXHY6T2ayUf s+k9eLKq031KA== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-05v.sys.comcast.net with comcast id elQV1s00A3KdFy101lQVdd; Tue, 05 Apr 2016 21:24:30 +0000 To: "Drage, Keith (Nokia - GB)" , "mmusic@ietf.org" References: <949EF20990823C4C85C18D59AA11AD8BADEB9F2E@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5703E549.1090805@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8BADEBA390@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Paul Kyzivat Message-ID: <57042D0D.90303@alum.mit.edu> Date: Tue, 5 Apr 2016 17:24:29 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADEBA390@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] IANA registry structure for IANA attributes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 21:24:33 -0000 On 4/5/16 4:18 PM, Drage, Keith (Nokia - GB) wrote: > Paul said: > > " But there is an ongoing debate on what sorts of things should be considered updates." > > My view is it is anything that changes the definition of the attribute, i.e. something that extends the attribute or makes new general requirements (not just rescoping). Appearance in an example does not count. I'll agree with you that dcsa usage can be considered as a sub-case of media level. > Paul said: > > " Can't the same be said about session/media/source level?" > > My answer is that in my view we are still talking attributes essentially being used at media level. Source level also qualifies as a sub-case of media level. So why distinguish source level and not dcsa level? > It just happens to relate to a media that is a subchannel within the datachannel, but it is still media. As such in general the attribute usage does not change, and no harm results. > > So my view is that all attributes that are defined as media attributes can be dcsa attributes (and we can add the caveat that "unless otherwise specified", but I do not think it will come up very often). Yes that needs to be written in a specification somewhere. I'd note that some will be also be disqualified for conditions already specified at source definition, like those any that relate specifically to rtp streams. We don't have any yet, but I expect will will eventually get some attributes that are only defined for use with data channel protocols, and so only with dcsa, not at the other "levels". And if we are trying to simplify, why distinguish between session level and media level? Many attributes can be used both places. And almost all attributes have further constraints on where they can be used. Thanks, Paul > Keith > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of EXT Paul Kyzivat > Sent: 05 April 2016 17:18 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] IANA registry structure for IANA attributes > > On 4/5/16 10:38 AM, Drage, Keith (Nokia - GB) wrote: >> Firstly I agree with Cullen that if any RFC updates the semantics of an existing attribute (i.e. makes normative changes to it) then that RFC formally needs to update the prior RFC. >> >> The registry should allow multiple references to RFCs where those RFCs make define additional semantics to an attribute, and MMUSIC should attempt to revise the attribute registry if these are missing. > > At least we agree on the above. :-) > > But there is an ongoing debate on what sorts of things should be considered updates. > > My desire is, given a sample usage of an attribute, to find the document that defines that usage. Preferably, I want to avoid having to read a lot of extraneous documents. > >> I think the separation of attributes into multiple subregistries is a bit historical rather than something that is needed. > > It predates my awareness of SDP, so I can only speculate about the thinking that led to it. > >> I am not proposing taking it away (although conversely would not object if it did provided this information was normatively clear in the base RFCs), but it goes beyond what is required. > > I *think* this info is available in documents for all the existing attributes, with regard to the session/media-level distinction. > > And I think (without looking) that specifications for attributes that can be used at source level say so. > > What *isn't* in existing documents in explicit indication that an attribute is *not* defined for use at source level. > > I suppose this could be dealt with by having 4566bis specify that any attribute definition that doesn't explicitly specify validity at source level is *not* valid at source level. > > (Note: there is only *one* attribute (fmtp) that is defined at source level *and* at another level.) > >> I do not think there is anything special about dcsa usage. Most dcsa usage does not change the semantics of the underlying attributes. Obviously if dcsa usage does change the semantics of an underlying attribute then the dcsa usage document should update the reference list. I do not think the msrp dcsa document makes any semantic change to any MSRP attributes - they can just be used. >> >> I have a problem with a new DCSA level if it implies that an attribute cannot be used within dsca if it does not appear in this list. > > Can't the same be said about session/media/source level? > > In a syntactic sense I can use any attribute at any level. It is just that a lot of them won't be valid in many contexts. > > Specifically regarding dcsa, it requires a new specification to say how a protocol that runs over UDP or TCP will be mapped onto a data channel. > That mapping MAY say that all the attributes that apply on the original transport still apply on the data channel. Or maybe not. And which attributes are meaningful will still depend on which (sub)protocol is being run on that data channel. > > Of course the same is true for the existing protocols. Not all attributes are meaningful with all m-line proto values. (For instance, many attributes are only meaningful with the RTP family of proto > values.) And we don't (currently) put that info into the registry. > (Maybe we should.) > > This isn't a big deal if all the relevant documents can be found (directly or indirectly) from the references in the registry, and there aren't very many of those. > > If we start to have numerous documents for an attribute, then having > *something* in the registry to help choose among them would be helpful. > > Thanks, > Paul > >> Regards >> >> Keith >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Tue Apr 5 14:44:10 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DA112D1F0 for ; Tue, 5 Apr 2016 14:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 bgEvMx_mVsm2 for ; Tue, 5 Apr 2016 14:44:02 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15B8712D179 for ; Tue, 5 Apr 2016 14:44:00 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id g185so34875105ioa.2 for ; Tue, 05 Apr 2016 14:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Wsluz0qc/0Zv5nFdADXJdH9DxCvAMYoq11wcr8CeqWA=; b=cDBNJzGGq6IJRlVCxp0cGODlyGVnKl8dXAyMcgJs/L4Ao5wjlVZ0ZLQ2rk1u3lJm0B bzyqHA1odg14s3nMCywvjZqOKhGy+pg4w2W2w+nA3umbaDS3iRKvFUVzU6HTsyWn/j69 3yPZJ5viimDzQi/7bwPfyb5bsQEKu/jeek3TKbn8Y5yTUESqt0bJm3aDf7x1/2nZ6LYa FasfMqh3cd8wwG1buS8d3qZzqEFJ7tYOai14KxCN3AE10y9APSAbqLVhkN0pJSsZUY2f zf/CMpl35hD9WoqqVp3uMYrK634hf3+btBwKzV6v9Ve7aAi8Q5cuv0jHk2FXm2Np8CiW j/XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Wsluz0qc/0Zv5nFdADXJdH9DxCvAMYoq11wcr8CeqWA=; b=THNcyJe0JdsfFmCs3nRowZBsEUEi26+QPm/cxMGoq1FG+B/68zs6SqbXWmNXxBME2u EzFMQwNYfApBRfNo+iJ1K/UpRc4/0MlYp6nW08Hh7SpZv3FAW+qx++CQKh+Nym8bqAQ9 9D8JYlRoWRD7wfwJVb0vR+fBNq7DjPoXOGaVn3zp3eL2AOGWvhI3ifA+HrLes/BKiJ1w rhESwM6T8gMuJ47+BpPBJAs0AxkP1TWcnjWS084dZi5e98dVeITAw8m/X7CjzyBZKFVB rfaDhOP7EXTM1I6LSqBhWcP0M93i80H04P7PSeenkSfj+E8khb4IOKqFlGxsegGJK8cf CPEA== X-Gm-Message-State: AD7BkJJnyt0YnyxiDg9qe7AqNFKhUNA8yfj0GQadCjrOgd9RRdkGmp4/yRomVX4fxKdd+Q== X-Received: by 10.107.165.17 with SMTP id o17mr20089136ioe.187.1459892220364; Tue, 05 Apr 2016 14:37:00 -0700 (PDT) Received: from mail-io0-f182.google.com (mail-io0-f182.google.com. [209.85.223.182]) by smtp.gmail.com with ESMTPSA id h90sm108147iod.41.2016.04.05.14.36.59 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2016 14:36:59 -0700 (PDT) Received: by mail-io0-f182.google.com with SMTP id g185so34707453ioa.2 for ; Tue, 05 Apr 2016 14:36:59 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr12068464ioe.38.1459892219257; Tue, 05 Apr 2016 14:36:59 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Tue, 5 Apr 2016 14:36:59 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Apr 2016 17:36:59 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Justin Uberti Content-Type: multipart/mixed; boundary=001a1140b472246d8d052fc3a50b Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] a=rtcp-mux-exclusive vs a=rtcp:0 compression X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 21:44:08 -0000 --001a1140b472246d8d052fc3a50b Content-Type: multipart/alternative; boundary=001a1140b472246d89052fc3a509 --001a1140b472246d89052fc3a509 Content-Type: text/plain; charset=UTF-8 I have modified the proposed SDP slightly. I have removed IN IP4 0.0.0.0 from a=rtcp attribute. I cannot find a place that states that a=rtcp is required when rtcp-mux is used, so I removed a=rtcp from the rtcp-mux-exclusive examples. Also, since we are shaving bits, I did a version with SDP attribute named rtcp-mux-only, which is 5 bytes shorter. So, my results are: | port 0 | -exclusive | -only | --------------------------------------------- Uncompressed | 1438 | 1462 | 1452 | Compressed | 716 | 725 | 720 | Regards, _____________ Roman Shpount On Tue, Apr 5, 2016 at 10:14 AM, Justin Uberti wrote: > Minor point for the beauty contest... > > Compressing the attached SDP files (adapted from the examples in > https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-14#section-7.1) with > gzip (default settings) gives the following output: > > | port 0 | -exclusive | > ------------------------------------- > Uncompressed | 1467 | 1487 | > Compressed | 723 | 739 | > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a1140b472246d89052fc3a509 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have modified the proposed SDP slightly. I have removed = IN IP4 0.0.0.0 from a=3Drtcp attribute. I cannot find a place that states t= hat a=3Drtcp is required when rtcp-mux is used, so I removed a=3Drtcp from = the rtcp-mux-exclusive examples. Also, since we are shaving bits, I did a v= ersion with SDP attribute named rtcp-mux-only, which is 5 bytes shorter. So= , my results are:

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | port 0 | -exc= lusive=C2=A0|=C2=A0-only=C2=A0|
---------------------------------------------
Uncomp= ressed =C2=A0| =C2=A0 1438 | =C2=A0 =C2=A0 =C2=A0 1462 |=C2=A0 1452 |<= /div>
Compressed =C2=A0 =C2=A0| =C2=A0 =C2=A0716 | =C2=A0 =C2=A0 = =C2=A0 =C2=A0725 |=C2=A0 =C2=A0720 |

Regards,

_____________
Roman Shpou= nt

On Tue, Apr 5, 2016 at 10:14 AM, Justin Uber= ti <juberti@google.com> wrote:
Minor point for the beauty contest...

=
Compressing the attached SDP files (adapted from the examples in https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-14#secti= on-7.1) with gzip (default settings) gives the following output:
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | port 0 | -exclusive |
=
----------------------= ---------------
Uncomp= ressed =C2=A0| =C2=A0 1467 | =C2=A0 =C2=A0 =C2=A0 1487 |
<= font face=3D"monospace, monospace">Compressed =C2=A0 =C2=A0| =C2=A0 =C2=A07= 23 | =C2=A0 =C2=A0 =C2=A0 =C2=A0739 |



_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


--001a1140b472246d89052fc3a509-- --001a1140b472246d8d052fc3a50b Content-Type: application/octet-stream; name="example71-offer-0.sdp" Content-Disposition: attachment; filename="example71-offer-0.sdp" Content-Transfer-Encoding: base64 X-Attachment-Id: f_imny0jod2 dj0wCm89LSA0OTYyMzAzMzMzMTc5ODcxNzIyIDEgSU4gSVA0IDAuMC4wLjAKcz0tCnQ9MCAwCmE9 Z3JvdXA6QlVORExFIGExIHYxCmE9aWNlLW9wdGlvbnM6dHJpY2tsZQptPWF1ZGlvIDkgVURQL1RM Uy9SVFAvU0FWUEYgOTYgMCA4IDk3IDk4CmM9SU4gSVA0IDAuMC4wLjAKYT1taWQ6YTEKYT1ydGNw OjAKYT1tc2lkOjQ3MDE3ZmVlLWI2YzEtNDE2Mi05MjljLWEyNTExMDI1MjQwMCBmODMwMDZjNS1h MGZmLTRlMGEtOWVkOS1kM2U2NzQ3YmU3ZDkKYT1zZW5kcmVjdgphPXJ0cG1hcDo5NiBvcHVzLzQ4 MDAwLzIKYT1ydHBtYXA6MCBQQ01VLzgwMDAKYT1ydHBtYXA6OCBQQ01BLzgwMDAKYT1ydHBtYXA6 OTcgdGVsZXBob25lLWV2ZW50LzgwMDAKYT1ydHBtYXA6OTggdGVsZXBob25lLWV2ZW50LzQ4MDAw CmE9bWF4cHRpbWU6MTIwCmE9aWNlLXVmcmFnOkVURW4KYT1pY2UtcHdkOk90U0swV3BOdHBVamtZ NCs4NmpzN1pRbAphPWZpbmdlcnByaW50OnNoYS0yNTYgMTk6RTI6MUM6M0I6NEI6OUY6ODE6RTY6 Qjg6NUM6RjQ6QTU6QTg6RDg6NzM6MDQ6QkI6MDU6MkY6NzA6OUY6MDQ6QTk6MEU6MDU6RTk6MjY6 MzM6RTg6NzA6ODg6QTIKYT1zZXR1cDphY3RwYXNzCmE9cnRjcC1tdXgKYT1ydGNwLXJzaXplCmE9 ZXh0bWFwOjEgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c3NyYy1hdWRpby1sZXZlbAphPWV4 dG1hcDoyIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNkZXM6bWlkCmE9c3NyYzoxNzMyODQ2 MzgwIGNuYW1lOkVvY1VHMWYwZmNnL3l2WTcKbT12aWRlbyA5IFVEUC9UTFMvUlRQL1NBVlBGIDEw MCAxMDEKYz1JTiBJUDQgMC4wLjAuMAphPXJ0Y3A6MAphPW1pZDp2MQphPW1zaWQ6NjEzMTc0ODQt MmVkNC00OWQ3LTllYjctMTQxNDMyMmE3YWFlIGYzMGJkYjRhLTVkYjgtNDliNS1iY2RjLWUwYzlh MjMxNzJlMAphPXNlbmRyZWN2CmE9cnRwbWFwOjEwMCBWUDgvOTAwMDAKYT1ydHBtYXA6MTAxIHJ0 eC85MDAwMAphPWZtdHA6MTAxIGFwdD0xMDAKYT1pY2UtdWZyYWc6QkdLawphPWljZS1wd2Q6bXF5 V3NBanZ0S3dUR252aFB6dFE5bUlmCmE9ZmluZ2VycHJpbnQ6c2hhLTI1NiAxOTpFMjoxQzozQjo0 Qjo5Rjo4MTpFNjpCODo1QzpGNDpBNTpBODpEODo3MzowNDpCQjowNToyRjo3MDo5RjowNDpBOTow RTowNTpFOToyNjozMzpFODo3MDo4ODpBMgphPXNldHVwOmFjdHBhc3MKYT1ydGNwLW11eAphPXJ0 Y3AtcnNpemUKYT1leHRtYXA6MyB1cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzZGVzOm1pZAph PXJ0Y3AtZmI6MTAwIGNjbSBmaXIKYT1ydGNwLWZiOjEwMCBuYWNrCmE9cnRjcC1mYjoxMDAgbmFj ayBwbGkKYT1zc3JjOjEzNjY3ODEwODMgY25hbWU6RW9jVUcxZjBmY2cveXZZNwphPXNzcmM6MTM2 Njc4MTA4NCBjbmFtZTpFb2NVRzFmMGZjZy95dlk3CmE9c3NyYy1ncm91cDpGSUQgMTM2Njc4MTA4 MyAxMzY2NzgxMDg0Cg== --001a1140b472246d8d052fc3a50b Content-Type: application/octet-stream; name="example71-offer-exclusive.sdp" Content-Disposition: attachment; filename="example71-offer-exclusive.sdp" Content-Transfer-Encoding: base64 X-Attachment-Id: f_imny0joq3 dj0wCm89LSA0OTYyMzAzMzMzMTc5ODcxNzIyIDEgSU4gSVA0IDAuMC4wLjAKcz0tCnQ9MCAwCmE9 Z3JvdXA6QlVORExFIGExIHYxCmE9aWNlLW9wdGlvbnM6dHJpY2tsZQptPWF1ZGlvIDkgVURQL1RM Uy9SVFAvU0FWUEYgOTYgMCA4IDk3IDk4CmM9SU4gSVA0IDAuMC4wLjAKYT1taWQ6YTEKYT1tc2lk OjQ3MDE3ZmVlLWI2YzEtNDE2Mi05MjljLWEyNTExMDI1MjQwMCBmODMwMDZjNS1hMGZmLTRlMGEt OWVkOS1kM2U2NzQ3YmU3ZDkKYT1zZW5kcmVjdgphPXJ0cG1hcDo5NiBvcHVzLzQ4MDAwLzIKYT1y dHBtYXA6MCBQQ01VLzgwMDAKYT1ydHBtYXA6OCBQQ01BLzgwMDAKYT1ydHBtYXA6OTcgdGVsZXBo b25lLWV2ZW50LzgwMDAKYT1ydHBtYXA6OTggdGVsZXBob25lLWV2ZW50LzQ4MDAwCmE9bWF4cHRp bWU6MTIwCmE9aWNlLXVmcmFnOkVURW4KYT1pY2UtcHdkOk90U0swV3BOdHBVamtZNCs4NmpzN1pR bAphPWZpbmdlcnByaW50OnNoYS0yNTYgMTk6RTI6MUM6M0I6NEI6OUY6ODE6RTY6Qjg6NUM6RjQ6 QTU6QTg6RDg6NzM6MDQ6QkI6MDU6MkY6NzA6OUY6MDQ6QTk6MEU6MDU6RTk6MjY6MzM6RTg6NzA6 ODg6QTIKYT1zZXR1cDphY3RwYXNzCmE9cnRjcC1tdXgKYT1ydGNwLW11eC1leGNsdXNpdmUKYT1y dGNwLXJzaXplCmE9ZXh0bWFwOjEgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c3NyYy1hdWRp by1sZXZlbAphPWV4dG1hcDoyIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNkZXM6bWlkCmE9 c3NyYzoxNzMyODQ2MzgwIGNuYW1lOkVvY1VHMWYwZmNnL3l2WTcKbT12aWRlbyA5IFVEUC9UTFMv UlRQL1NBVlBGIDEwMCAxMDEKYz1JTiBJUDQgMC4wLjAuMAphPW1pZDp2MQphPW1zaWQ6NjEzMTc0 ODQtMmVkNC00OWQ3LTllYjctMTQxNDMyMmE3YWFlIGYzMGJkYjRhLTVkYjgtNDliNS1iY2RjLWUw YzlhMjMxNzJlMAphPXNlbmRyZWN2CmE9cnRwbWFwOjEwMCBWUDgvOTAwMDAKYT1ydHBtYXA6MTAx IHJ0eC85MDAwMAphPWZtdHA6MTAxIGFwdD0xMDAKYT1pY2UtdWZyYWc6QkdLawphPWljZS1wd2Q6 bXF5V3NBanZ0S3dUR252aFB6dFE5bUlmCmE9ZmluZ2VycHJpbnQ6c2hhLTI1NiAxOTpFMjoxQzoz Qjo0Qjo5Rjo4MTpFNjpCODo1QzpGNDpBNTpBODpEODo3MzowNDpCQjowNToyRjo3MDo5RjowNDpB OTowRTowNTpFOToyNjozMzpFODo3MDo4ODpBMgphPXNldHVwOmFjdHBhc3MKYT1ydGNwLW11eAph PXJ0Y3AtbXV4LWV4Y2x1c2l2ZQphPXJ0Y3AtcnNpemUKYT1leHRtYXA6MyB1cm46aWV0ZjpwYXJh bXM6cnRwLWhkcmV4dDpzZGVzOm1pZAphPXJ0Y3AtZmI6MTAwIGNjbSBmaXIKYT1ydGNwLWZiOjEw MCBuYWNrCmE9cnRjcC1mYjoxMDAgbmFjayBwbGkKYT1zc3JjOjEzNjY3ODEwODMgY25hbWU6RW9j VUcxZjBmY2cveXZZNwphPXNzcmM6MTM2Njc4MTA4NCBjbmFtZTpFb2NVRzFmMGZjZy95dlk3CmE9 c3NyYy1ncm91cDpGSUQgMTM2Njc4MTA4MyAxMzY2NzgxMDg0Cg== --001a1140b472246d8d052fc3a50b Content-Type: application/octet-stream; name="example71-offer-only.sdp" Content-Disposition: attachment; filename="example71-offer-only.sdp" Content-Transfer-Encoding: base64 X-Attachment-Id: f_imny0jow4 dj0wCm89LSA0OTYyMzAzMzMzMTc5ODcxNzIyIDEgSU4gSVA0IDAuMC4wLjAKcz0tCnQ9MCAwCmE9 Z3JvdXA6QlVORExFIGExIHYxCmE9aWNlLW9wdGlvbnM6dHJpY2tsZQptPWF1ZGlvIDkgVURQL1RM Uy9SVFAvU0FWUEYgOTYgMCA4IDk3IDk4CmM9SU4gSVA0IDAuMC4wLjAKYT1taWQ6YTEKYT1tc2lk OjQ3MDE3ZmVlLWI2YzEtNDE2Mi05MjljLWEyNTExMDI1MjQwMCBmODMwMDZjNS1hMGZmLTRlMGEt OWVkOS1kM2U2NzQ3YmU3ZDkKYT1zZW5kcmVjdgphPXJ0cG1hcDo5NiBvcHVzLzQ4MDAwLzIKYT1y dHBtYXA6MCBQQ01VLzgwMDAKYT1ydHBtYXA6OCBQQ01BLzgwMDAKYT1ydHBtYXA6OTcgdGVsZXBo b25lLWV2ZW50LzgwMDAKYT1ydHBtYXA6OTggdGVsZXBob25lLWV2ZW50LzQ4MDAwCmE9bWF4cHRp bWU6MTIwCmE9aWNlLXVmcmFnOkVURW4KYT1pY2UtcHdkOk90U0swV3BOdHBVamtZNCs4NmpzN1pR bAphPWZpbmdlcnByaW50OnNoYS0yNTYgMTk6RTI6MUM6M0I6NEI6OUY6ODE6RTY6Qjg6NUM6RjQ6 QTU6QTg6RDg6NzM6MDQ6QkI6MDU6MkY6NzA6OUY6MDQ6QTk6MEU6MDU6RTk6MjY6MzM6RTg6NzA6 ODg6QTIKYT1zZXR1cDphY3RwYXNzCmE9cnRjcC1tdXgKYT1ydGNwLW11eC1vbmx5CmE9cnRjcC1y c2l6ZQphPWV4dG1hcDoxIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNzcmMtYXVkaW8tbGV2 ZWwKYT1leHRtYXA6MiB1cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzZGVzOm1pZAphPXNzcmM6 MTczMjg0NjM4MCBjbmFtZTpFb2NVRzFmMGZjZy95dlk3Cm09dmlkZW8gOSBVRFAvVExTL1JUUC9T QVZQRiAxMDAgMTAxCmM9SU4gSVA0IDAuMC4wLjAKYT1taWQ6djEKYT1tc2lkOjYxMzE3NDg0LTJl ZDQtNDlkNy05ZWI3LTE0MTQzMjJhN2FhZSBmMzBiZGI0YS01ZGI4LTQ5YjUtYmNkYy1lMGM5YTIz MTcyZTAKYT1zZW5kcmVjdgphPXJ0cG1hcDoxMDAgVlA4LzkwMDAwCmE9cnRwbWFwOjEwMSBydHgv OTAwMDAKYT1mbXRwOjEwMSBhcHQ9MTAwCmE9aWNlLXVmcmFnOkJHS2sKYT1pY2UtcHdkOm1xeVdz QWp2dEt3VEdudmhQenRROW1JZgphPWZpbmdlcnByaW50OnNoYS0yNTYgMTk6RTI6MUM6M0I6NEI6 OUY6ODE6RTY6Qjg6NUM6RjQ6QTU6QTg6RDg6NzM6MDQ6QkI6MDU6MkY6NzA6OUY6MDQ6QTk6MEU6 MDU6RTk6MjY6MzM6RTg6NzA6ODg6QTIKYT1zZXR1cDphY3RwYXNzCmE9cnRjcC1tdXgKYT1ydGNw LW11eC1vbmx5CmE9cnRjcC1yc2l6ZQphPWV4dG1hcDozIHVybjppZXRmOnBhcmFtczpydHAtaGRy ZXh0OnNkZXM6bWlkCmE9cnRjcC1mYjoxMDAgY2NtIGZpcgphPXJ0Y3AtZmI6MTAwIG5hY2sKYT1y dGNwLWZiOjEwMCBuYWNrIHBsaQphPXNzcmM6MTM2Njc4MTA4MyBjbmFtZTpFb2NVRzFmMGZjZy95 dlk3CmE9c3NyYzoxMzY2NzgxMDg0IGNuYW1lOkVvY1VHMWYwZmNnL3l2WTcKYT1zc3JjLWdyb3Vw OkZJRCAxMzY2NzgxMDgzIDEzNjY3ODEwODQK --001a1140b472246d8d052fc3a50b-- From nobody Thu Apr 7 05:31:50 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE0A12D892 for ; Thu, 7 Apr 2016 05:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 CbwAO9lrfDk6 for ; Thu, 7 Apr 2016 05:31:42 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D801B12D88D for ; Thu, 7 Apr 2016 05:31:42 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u37CUW26031635 for ; Thu, 7 Apr 2016 08:31:42 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 2201q0mvck-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 07 Apr 2016 08:31:42 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Thu, 7 Apr 2016 07:31:41 -0500 From: Jonathan Lennox To: mmusic Thread-Topic: 4572 update: forbid weak hashes? Thread-Index: AQHRkMlvyALEPXgXDkKRhXLaT8/AmA== Date: Thu, 7 Apr 2016 12:31:41 +0000 Message-ID: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.137.240] Content-Type: text/plain; charset="utf-8" Content-ID: <7077716344F1C142B8E489690EADB8B5@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-07_08:2016-04-07,2016-04-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1601100000 definitions=main-1604070181 Archived-At: Subject: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 12:31:49 -0000 SGksIGFsbCDigJQNCg0KRm9yIHRoZSBSRkMgNDU3MiB1cGRhdGUsIEkgdGhpbmsgd2Ugc2hvdWxk IGFkZCB0aGF0IHJlY2VpdmVycyBNVVNUIE5PVCBtYXRjaCBvbiBmaW5nZXJwcmludHMgY29tcHV0 ZWQgd2l0aCB3ZWFrIGhhc2hlcywgYW5kIHNlbmRlcnMgU0hPVUxEIE5PVCBzZW5kIHRoZW0uDQoN CklmIHdlIGRvIHRoaXMsIGl0IHJlbW92ZXMgc29tZSBvZiB0aGUgcXVlc3Rpb25zIGFib3V0IOKA nGRvIHlvdSBuZWVkIHRvIHZlcmlmeSBhIGZpbmdlcnByaW50IGZvciBldmVyeSBoYXNoIGFsZ29y aXRobSwgb3Igb25seSBvbmUu4oCdDQoNCldlYWsgaGFzaGVzIGRlZmluaXRlbHkgaW5jbHVkZSBN RDIgYW5kIE1ENS4gIEkgZ3Vlc3Mgd2Ugc3RpbGwgd2FudCBTSEEtMSB0byBiZSBzdXBwb3J0ZWQs IHRob3VnaD8NCg0K From nobody Thu Apr 7 06:35:14 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2901E12D816 for ; Thu, 7 Apr 2016 06:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dldQPrOUV8l5 for ; Thu, 7 Apr 2016 06:35:10 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58C812D12E for ; Thu, 7 Apr 2016 06:35:09 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-dd-5706620ce382 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 33.05.22880.C0266075; Thu, 7 Apr 2016 15:35:08 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0248.002; Thu, 7 Apr 2016 15:35:07 +0200 From: Christer Holmberg To: Jonathan Lennox , mmusic Thread-Topic: 4572 update: forbid weak hashes? Thread-Index: AQHRkMlvyALEPXgXDkKRhXLaT8/AmJ9+gkOg Date: Thu, 7 Apr 2016 13:35:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> In-Reply-To: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2J7iC5PElu4wdu1Qhb7F59ntpi6/DGL A5PHkiU/mTzant1hD2CK4rJJSc3JLEst0rdL4MpY1f+dtWABZ8X6J62MDYwNnF2MnBwSAiYS Fzvms0HYYhIX7q0Hsrk4hASOMEpcXPCKFcJZxChxcuUrxi5GDg42AQuJ7n/aIA0iAk4SR+es ZAaxhQV0JTZMncsEEdeT+DVtOguEbSRx9tQCVhCbRUBF4vaRqYwgNq+Ar8SHV6/BeoUEbCTu bboA1sspYCvRPvsYO4jNCHTQ91NrwOLMAuISt57MZ4I4VEBiyZ7zzBC2qMTLx/9YIWwliRXb L4GdySygKbF+lz5Eq6LElO6H7BBrBSVOznzCMoFRdBaSqbMQOmYh6ZiFpGMBI8sqRtHi1OLi 3HQjY73Uoszk4uL8PL281JJNjMAYObjlt+4OxtWvHQ8xCnAwKvHwKuxnDRdiTSwrrsw9xCjB wawkwns4nC1ciDclsbIqtSg/vqg0J7X4EKM0B4uSOG9O5L8wIYH0xJLU7NTUgtQimCwTB6dU AyPvgXWVl9YsC9Fva43/Umv7+sj+tycdfI7Zf6lYcOXLZLtFHYfroxPTXXbeYOr8GPzR/G2/ UrbNT/3pb6d1bPzFwHVMrWzLvOWcft/mzuo75OAXq3B0bu6sTfGqSZ5m/r9sjv/625TLXqpT c8Vv3mY+68eX7r/hmH+df5PevjWnojrad5f08CxQYinOSDTUYi4qTgQA/xXJiY0CAAA= Archived-At: Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 13:35:12 -0000 SGkgSm9uYXRoYW4sDQoNCj5Gb3IgdGhlIFJGQyA0NTcyIHVwZGF0ZSwgSSB0aGluayB3ZSBzaG91 bGQgYWRkIHRoYXQgcmVjZWl2ZXJzIE1VU1QgTk9UIG1hdGNoIG9uIGZpbmdlcnByaW50cyA+Y29t cHV0ZWQgd2l0aCB3ZWFrIGhhc2hlcywgYW5kIHNlbmRlcnMgU0hPVUxEIE5PVCBzZW5kIHRoZW0u DQo+DQo+SWYgd2UgZG8gdGhpcywgaXQgcmVtb3ZlcyBzb21lIG9mIHRoZSBxdWVzdGlvbnMgYWJv dXQg4oCcZG8geW91IG5lZWQgdG8gdmVyaWZ5IGEgZmluZ2VycHJpbnQgZm9yIGV2ZXJ5ID5oYXNo IGFsZ29yaXRobSwgb3Igb25seSBvbmUu4oCdDQoNCldoYXQgYWJvdXQgc2F5aW5nIHRoYXQgb25l IE1VU1QgbWF0Y2ggb24gdGhlIHN0cm9uZ2VzdCBoYXNoIHJlY2VpdmVkPyANCg0KVGhlbiwgaWYg eW91IG9ubHkgcmVjZWl2ZSBhIHdlYWsgaGFzaCwgaXNuJ3QgaXQgc3RpbGwgYmV0dGVyIHRvIG1h dGNoIHRoYW4gZG9pbmcgbm90aGluZz8NCg0KPldlYWsgaGFzaGVzIGRlZmluaXRlbHkgaW5jbHVk ZSBNRDIgYW5kIE1ENS4gIEkgZ3Vlc3Mgd2Ugc3RpbGwgd2FudCBTSEEtMSB0byBiZSBzdXBwb3J0 ZWQsIHRob3VnaD8NCg0KSSdsbCBsZXQgb3RoZXJzIGRlY2lkZSBvbiB3aGV0aGVyIHdlIHN0aWxs IHdhbnQgdG8gYWxsb3cgU0hBLTEsIGJ1dCB0aGUgc3VnZ2VzdGlvbiBpcyB0byBtYWtlIFNIQS0y NTYgdGhlIHByZWZlcnJlZCBvbmUuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlz dA0KbW11c2ljQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21tdXNpYw0K From nobody Thu Apr 7 06:45:19 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9808812D18A for ; Thu, 7 Apr 2016 06:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ZZdsnPwAgbli for ; Thu, 7 Apr 2016 06:45:15 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F8E12D100 for ; Thu, 7 Apr 2016 06:45:14 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u37Dio7k011791; Thu, 7 Apr 2016 09:45:10 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 2201q9mv2e-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 07 Apr 2016 09:45:10 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Thu, 7 Apr 2016 08:45:10 -0500 From: Jonathan Lennox To: Christer Holmberg Thread-Topic: 4572 update: forbid weak hashes? Thread-Index: AQHRkMlwm1IOS0v/nky6qqsTs4iOQZ9+1teAgAACzQA= Date: Thu, 7 Apr 2016 13:45:09 +0000 Message-ID: <7FAC6369-90CA-4C50-9EC6-EF7E835F9DC4@vidyo.com> References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.177.193] Content-Type: text/plain; charset="utf-8" Content-ID: <0B348DF1DEFF1D4B82936ECA1B656F05@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-07_10:2016-04-07,2016-04-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1601100000 definitions=main-1604070199 Archived-At: Cc: mmusic Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 13:45:17 -0000 DQo+IE9uIEFwciA3LCAyMDE2LCBhdCAxMDozNSBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBKb25hdGhhbiwNCj4g DQo+PiBGb3IgdGhlIFJGQyA0NTcyIHVwZGF0ZSwgSSB0aGluayB3ZSBzaG91bGQgYWRkIHRoYXQg cmVjZWl2ZXJzIE1VU1QgTk9UIG1hdGNoIG9uIGZpbmdlcnByaW50cyA+Y29tcHV0ZWQgd2l0aCB3 ZWFrIGhhc2hlcywgYW5kIHNlbmRlcnMgU0hPVUxEIE5PVCBzZW5kIHRoZW0uDQo+PiANCj4+IElm IHdlIGRvIHRoaXMsIGl0IHJlbW92ZXMgc29tZSBvZiB0aGUgcXVlc3Rpb25zIGFib3V0IOKAnGRv IHlvdSBuZWVkIHRvIHZlcmlmeSBhIGZpbmdlcnByaW50IGZvciBldmVyeSA+aGFzaCBhbGdvcml0 aG0sIG9yIG9ubHkgb25lLuKAnQ0KPiANCj4gV2hhdCBhYm91dCBzYXlpbmcgdGhhdCBvbmUgTVVT VCBtYXRjaCBvbiB0aGUgc3Ryb25nZXN0IGhhc2ggcmVjZWl2ZWQ/IA0KPiANCj4gVGhlbiwgaWYg eW91IG9ubHkgcmVjZWl2ZSBhIHdlYWsgaGFzaCwgaXNuJ3QgaXQgc3RpbGwgYmV0dGVyIHRvIG1h dGNoIHRoYW4gZG9pbmcgbm90aGluZz8NCg0KTm90IGlmIHRoZSBoYXNoIGlzIHNvIHdlYWsgaXTi gJlzIG5vdCBzZWN1cmUsIGFuZCBhIHBsYXVzaWJsZSBpbXBsZW1lbnRhdGlvbiB3b3VsZG7igJl0 IGJlIHVzaW5nIGl0LiAgU3VjaCBhbiBvZmZlciBtaWdodCBiZSBhIGJpZC1kb3duIGF0dGFjayBv ZiBzb21lIHNvcnQuICBZb3XigJlyZSBiZXR0ZXIgb2ZmIHJlamVjdGluZyB0aGUgc3RyZWFtLg0K DQo+PiBXZWFrIGhhc2hlcyBkZWZpbml0ZWx5IGluY2x1ZGUgTUQyIGFuZCBNRDUuICBJIGd1ZXNz IHdlIHN0aWxsIHdhbnQgU0hBLTEgdG8gYmUgc3VwcG9ydGVkLCB0aG91Z2g/DQo+IA0KPiBJJ2xs IGxldCBvdGhlcnMgZGVjaWRlIG9uIHdoZXRoZXIgd2Ugc3RpbGwgd2FudCB0byBhbGxvdyBTSEEt MSwgYnV0IHRoZSBzdWdnZXN0aW9uIGlzIHRvIG1ha2UgU0hBLTI1NiB0aGUgcHJlZmVycmVkIG9u ZS4NCg0KT2gsIGFic29sdXRlbHksIG5vIHF1ZXN0aW9uLiAgQnV0IHNpbmNlIDQ1NzIgcHJlZmVy cmVkIFNIQS0xLCBpdCBwcm9iYWJseSBuZWVkcyB0byBzdGF5IHN1cHBvcnRlZCBmb3Igc29tZSB0 aW1lLg== From nobody Thu Apr 7 07:05:16 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE9312D104 for ; Thu, 7 Apr 2016 07:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPOnQAFuyR43 for ; Thu, 7 Apr 2016 07:05:05 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44BCF12D501 for ; Thu, 7 Apr 2016 07:05:05 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-92-570668dff6ac Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 2F.FA.22880.FD866075; Thu, 7 Apr 2016 16:04:15 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0248.002; Thu, 7 Apr 2016 16:04:14 +0200 From: Christer Holmberg To: Jonathan Lennox Thread-Topic: 4572 update: forbid weak hashes? Thread-Index: AQHRkMlvyALEPXgXDkKRhXLaT8/AmJ9+gkOg///iCYCAACYSAA== Date: Thu, 7 Apr 2016 14:04:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F27D03@ESESSMB209.ericsson.se> References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <7FAC6369-90CA-4C50-9EC6-EF7E835F9DC4@vidyo.com> In-Reply-To: <7FAC6369-90CA-4C50-9EC6-EF7E835F9DC4@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbHdWJc/ky3c4OJpZYv9i88zW0xd/pjF gcljyZKfTB5tz+6wBzBFcdmkpOZklqUW6dslcGXsvrmRreAVZ8XWX8eZGhhPcHYxcnBICJhI tE1j7mLkBDLFJC7cW8/WxcjFISRwhFHi8o9TTBDOIkaJlvttzCANbAIWEt3/tEEaRAQ0JC4+ +8AGYjMLyEjMONvIBGILC+hKbJg6lwmiRk/i17TpLCCtIgJOEqu2ZoCEWQRUJM42fWMFCfMK +Ers+uwAsWkzo0T7rRdgrZwCthId+1+A3cYIdNv3U2uYIFaJS9x6Mp8J4mYBiSV7zkPdLyrx 8vE/VghbSWLF9kuMIPOZBTQl1u/Sh2hVlJjS/ZAdxOYVEJQ4OfMJywRGsVlIps5C6JiFpGMW ko4FjCyrGEWLU4uLc9ONjPVSizKTi4vz8/TyUks2MQLj5uCW37o7GFe/djzEKMDBqMTDq7Cf NVyINbGsuDL3EKMEB7OSCO+6FLZwId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rw5kf/ChATSE0tS s1NTC1KLYLJMHJxSDYw9lc2GZY2yf1Y3nFUPvbdwK8tvmdRt91WusPLert/Acbfb/oLPZb/r rw5HP0pQS55n13Ys+P6itGnndYR1ahnnMfOGb2o4OJ1JfUFUaB6ruKXVjHN7LN3qTpX8S1q3 POpZ5sEblxKPf6rd38a7pGHThbpZO607rxUKszRoyUWKRC48qSxg+k6JpTgj0VCLuag4EQBJ Gqa8lwIAAA== Archived-At: Cc: mmusic Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 14:05:14 -0000 SGksDQoNCj4+PiBGb3IgdGhlIFJGQyA0NTcyIHVwZGF0ZSwgSSB0aGluayB3ZSBzaG91bGQgYWRk IHRoYXQgcmVjZWl2ZXJzIE1VU1QgTk9UIG1hdGNoIG9uIGZpbmdlcnByaW50cyA+Pj4gY29tcHV0 ZWQgd2l0aCB3ZWFrIGhhc2hlcywgYW5kIHNlbmRlcnMgU0hPVUxEIE5PVCBzZW5kIHRoZW0uDQo+ Pj4gDQo+Pj4gSWYgd2UgZG8gdGhpcywgaXQgcmVtb3ZlcyBzb21lIG9mIHRoZSBxdWVzdGlvbnMg YWJvdXQg4oCcZG8geW91IG5lZWQgdG8gdmVyaWZ5IGEgZmluZ2VycHJpbnQgZm9yIGV2ZXJ5ID4+ PiBoYXNoIGFsZ29yaXRobSwgb3Igb25seSBvbmUu4oCdDQo+PiANCj4+IFdoYXQgYWJvdXQgc2F5 aW5nIHRoYXQgb25lIE1VU1QgbWF0Y2ggb24gdGhlIHN0cm9uZ2VzdCBoYXNoIHJlY2VpdmVkPyAN Cg0KQ2xhcmlmaWNhdGlvbjogb2YgdGhlIHJlY2VpdmVkIGhhc2hlcywgdGhlIHN0cm9uZ2VzdCBv bmUgdGhhdCB0aGUgcmVjZWl2ZXIgc3VwcG9ydA0KDQo+PiBUaGVuLCBpZiB5b3Ugb25seSByZWNl aXZlIGEgd2VhayBoYXNoLCBpc24ndCBpdCBzdGlsbCBiZXR0ZXIgdG8gbWF0Y2ggdGhhbiBkb2lu ZyBub3RoaW5nPw0KPg0KPk5vdCBpZiB0aGUgaGFzaCBpcyBzbyB3ZWFrIGl04oCZcyBub3Qgc2Vj dXJlLCBhbmQgYSBwbGF1c2libGUgaW1wbGVtZW50YXRpb24gd291bGRu4oCZdCBiZSB1c2luZyBp dC4gIFN1Y2ggPmFuIG9mZmVyIG1pZ2h0IGJlIGEgYmlkLWRvd24gYXR0YWNrIG9mIHNvbWUgc29y dC4gIFlvdeKAmXJlIGJldHRlciBvZmYgcmVqZWN0aW5nIHRoZSBzdHJlYW0uDQoNCkRvIHdlIGxl dCB0aGUgYXBwbGljYXRpb24gZGVjaWRlIHdoYXQgaXMgY29uc2lkZXJzICJ0b28gd2VhayIsIG9y IGRvIHdlIHdhbnQgdG8gc3BlY2lmeSBzb21ldGhpbmc/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVy DQoNCg== From nobody Thu Apr 7 07:06:16 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183BD12D1A4 for ; Thu, 7 Apr 2016 07:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1K2eHB_lonJB for ; Thu, 7 Apr 2016 07:06:09 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8DE612D104 for ; Thu, 7 Apr 2016 07:06:08 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id o126so72655068iod.0 for ; Thu, 07 Apr 2016 07:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=lqgEub5s5Zr24XWEb7gb3Rj9h36JjfWJ+9nGQLzaLfA=; b=M9BmDx1AZAJlz5upO64Ei2uL+CoXF5QkreacYalc6hmbkUDpgqlFv5jFd9nALMikwv Oz8Su2g8DvchH25Fnn15WYGH2z6mIJjrHtulydsOwCUXUJeAw5uS+Mdi2Ckrc5+ph0qA BNXkudlCSM79268Na6iW3lRHUsOz1Xop7DWmQyIQo9x0M8+Yr3p9O4RtcBbQqX7y1nc7 V7voSEm9XRcJywhQDdQXoq/vk8CkXgR/6B/TGpdTZ9C9nCe4J9Ogcq3wQtn2qOOw9kmk 6L/ldf9Xe3GklkuHkBKJAo0ve08aP3z+KwL29bXQjVpCWs9huvDM8gQZRaPYtLuWAil8 G4ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=lqgEub5s5Zr24XWEb7gb3Rj9h36JjfWJ+9nGQLzaLfA=; b=YTECS+qd1go25YHvgr5+pPZusr53vYl2LkZjjUwppwTMWLqFRsVxfekyLyj6qaQ3lW yqsoWrpYZaaU+B6Zmr/eFJIRYy9BtCPCSTa0mjr3uAfrD7w/qSx4KE2favSClaNftcil 3Dw10wdo5VHOoVXo2ORZIvr0i5+WINaMkC1pFRpPGzf3Pd5shSJm1+uv9LrbTN/HTEib 7ngDbnDrCP4ECCbbgu3/+d8I+PheaL/yr8KN+hd55GYYwlePNnqfm3bv/CL8WxHkfyY3 GRExIjD769FqrJ+pwgoHbEMm6MPGfRkNB2m6FQq4n7F8QZEAEbFXWVu50uzMyfb2fMxI O2jw== X-Gm-Message-State: AD7BkJK33m7AmXoxXT0dcyYEQksHZJUxsBm7o2Ul9YU+SAlL4mWLFCVKYxJ5U7jZ1FWfbzJCCqe9qaA9UkMT2g== MIME-Version: 1.0 X-Received: by 10.107.161.140 with SMTP id k134mr3889439ioe.190.1460037968100; Thu, 07 Apr 2016 07:06:08 -0700 (PDT) Received: by 10.36.43.5 with HTTP; Thu, 7 Apr 2016 07:06:08 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> Date: Thu, 7 Apr 2016 11:06:08 -0300 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 14:06:15 -0000 On 7 April 2016 at 10:35, Christer Holmberg wrote: >>If we do this, it removes some of the questions about =E2=80=9Cdo you nee= d to verify a fingerprint for every >hash algorithm, or only one.=E2=80=9D > > What about saying that one MUST match on the strongest hash received? Maybe three pieces of advice are right. 1. Implement the strongest hash you can 2. Check all the hashes you can 3. Don't accept a session if you can only check weak hashes From nobody Thu Apr 7 07:09:53 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38EE12D0B9 for ; Thu, 7 Apr 2016 07:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49hxAsQoHCGX for ; Thu, 7 Apr 2016 07:09:49 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A7A312D09A for ; Thu, 7 Apr 2016 07:09:48 -0700 (PDT) X-AuditID: c1b4fb25-f79f86d00000400a-90-57066a2bcffa Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FB.CC.16394.B2A66075; Thu, 7 Apr 2016 16:09:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0248.002; Thu, 7 Apr 2016 16:08:58 +0200 From: Christer Holmberg To: Martin Thomson Thread-Topic: [MMUSIC] 4572 update: forbid weak hashes? Thread-Index: AQHRkMlvyALEPXgXDkKRhXLaT8/AmJ9+gkOg///n5gCAACIUsA== Date: Thu, 7 Apr 2016 14:08:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F27D6E@ESESSMB209.ericsson.se> References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGbE9UFc7iy3c4NlfOYv9i88zW1w784/R YuryxywOzB47Z91l91iy5CeTR9uzO+wBzFFcNimpOZllqUX6dglcGR9O3mcv6OOqWDvlKWsD 4xvOLkZ2DgkBE4lJal2MnECWmMSFe+vZuhi5OIQEjjBKHH57HcpZBORsXMvexcjBwSZgIdH9 TxukQURAV2LR2QfsIDazgJPEn533mEBKhAXMJK4dj4UoMZf42dDIAmE7SSw7sI0RxGYRUJF4 u30ymM0r4Cvxc8YMJohVxxklfp/aAjaTUyBQ4vSadWDNjEDHfT+1hglil7jErSfzmSCOFpBY suc8M4QtKvHy8T9WCFtJYsX2S4wg9zALaEqs36UP0aooMaX7ITvEXkGJkzOfsExgFJuFZOos hI5ZSDpmIelYwMiyilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMwlg5u+a26g/HyG8dDjAIc jEo8vAr7WcOFWBPLiitzDzFKcDArifCuS2ELF+JNSaysSi3Kjy8qzUktPsQozcGiJM6bHfkv TEggPbEkNTs1tSC1CCbLxMEp1cAodGXrkQnmnu02+qY1B6dNrkr9YV2see3wrbefJLKbFTcq ettuUObcfHHaGrnbU3fJnFmitJv9hP2pUN/5FhNVlf+c7hGftLKxfs6EB2vqwtrUQi4fV5N+ cfjjPu8byUrBuht+sn331SsrvfvMaJeikt2KbsZaz8qHz2/ZtGzV+RF60kM74mSREktxRqKh FnNRcSIAgGLygKECAAA= Archived-At: Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 14:09:52 -0000 SGkgTWFydGluLA0KDQpJJ2QgaGF2ZSB0byBkb3VibGUgY2hlY2sgdGhlIE1NVVNJQyBtaW51dGVz LCBidXQgaWYgSSByZW1lbWJlciBjb3JyZWN0bHkgcGVvcGxlIGRpZCBub3Qgd2FudCB0byBjaGVj ayBtdWx0aXBsZSBoYXNoZXMgKHBvaW50IDIpLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzpt YXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dIA0KU2VudDogMDcgQXByaWwgMjAxNiAxNzowNg0KVG86 IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpDYzog Sm9uYXRoYW4gTGVubm94IDxqb25hdGhhbkB2aWR5by5jb20+OyBtbXVzaWMgPG1tdXNpY0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSA0NTcyIHVwZGF0ZTogZm9yYmlkIHdlYWsgaGFz aGVzPw0KDQpPbiA3IEFwcmlsIDIwMTYgYXQgMTA6MzUsIENocmlzdGVyIEhvbG1iZXJnIDxjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPj5JZiB3ZSBkbyB0aGlzLCBpdCBy ZW1vdmVzIHNvbWUgb2YgdGhlIHF1ZXN0aW9ucyBhYm91dCDigJxkbyB5b3UgbmVlZCB0byB2ZXJp ZnkgYSBmaW5nZXJwcmludCBmb3IgZXZlcnkgPmhhc2ggYWxnb3JpdGhtLCBvciBvbmx5IG9uZS7i gJ0NCj4NCj4gV2hhdCBhYm91dCBzYXlpbmcgdGhhdCBvbmUgTVVTVCBtYXRjaCBvbiB0aGUgc3Ry b25nZXN0IGhhc2ggcmVjZWl2ZWQ/DQoNCk1heWJlIHRocmVlIHBpZWNlcyBvZiBhZHZpY2UgYXJl IHJpZ2h0Lg0KDQoxLiBJbXBsZW1lbnQgdGhlIHN0cm9uZ2VzdCBoYXNoIHlvdSBjYW4NCjIuIENo ZWNrIGFsbCB0aGUgaGFzaGVzIHlvdSBjYW4NCjMuIERvbid0IGFjY2VwdCBhIHNlc3Npb24gaWYg eW91IGNhbiBvbmx5IGNoZWNrIHdlYWsgaGFzaGVzDQo= From nobody Thu Apr 7 07:36:28 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E637912DA1B for ; Thu, 7 Apr 2016 07:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 Oe0vcMxwMva1 for ; Thu, 7 Apr 2016 07:36:25 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6AB012D964 for ; Thu, 7 Apr 2016 07:20:27 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id g185so95570531ioa.2 for ; Thu, 07 Apr 2016 07:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=km9Ts6Q/gBGS85BWQGsMPOn3iavKJvzAUYBURcFFn2U=; b=ZhEbF8hqpPBalma3zgkza0iPvKqoWSwYLBFIddyTmlI4S4OTZRJ2t0yRTz98d1yq5B NFYmpacjqqyu5Ry7hFNGvKVWvfCLIGLB9h6Pumz+sjfmohI7dkOn19ZxGNq3K+U9BjZh v+1pnT21LitmITHRs8p/qHop7Tz1ieCJNB9WRz93Z3dlsqtWl0YnfPpNYH7cXE3F81kz j890Y6AjcstjRVczp1v3c/4y5PR7WPgRifXNQsUyXp909q4wYriu6KBEGyMc3PVKT6Sg RmHI/NPiOS+LmdzvRV+h/S8x4w8k3Z6nyAPB1JBLUnp6ckFr7DD7lLtI4z44bmxYj8zI cFtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=km9Ts6Q/gBGS85BWQGsMPOn3iavKJvzAUYBURcFFn2U=; b=SvBvU/bYGlGQRDw6+6YFJdW3b/14jxoXY528AXL59AsX3Y1LecI3SNKLsjm1uAh4JQ kpGXzLl+hkvIAR7vLpHvlbsTyeczjX7a9H6OX9xtspgGQ6uIdnC2+F/IAXjue32kegfL eh2Kpr3sHKRBqyUI/6i6CgB4IA1meJ5QMh6luvJYP268InfG4947z9ILQyWku+I4WZ/b 9TV1SKo/O6UNd3glxT6L1NNebGtvCj2rrbX6Ng44YQeM7kFj1bPRHS1gCqfGyXsYYNiA TskAwMkNtSBYpPBANSaGTxy0qU4gUcmbhtFD92uYKREUoDwbCM85HAN0v/WUaTevkj3j SYHg== X-Gm-Message-State: AD7BkJKa+T/mGlVkmmoPK5oV4I4Ci9rzGFdgKIq15a9qwPSlnFmGa5w8G4al0gu1d90Hlg== X-Received: by 10.107.1.18 with SMTP id 18mr3716155iob.74.1460038827063; Thu, 07 Apr 2016 07:20:27 -0700 (PDT) Received: from mail-io0-f181.google.com (mail-io0-f181.google.com. [209.85.223.181]) by smtp.gmail.com with ESMTPSA id p1sm3710662iop.12.2016.04.07.07.20.25 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 07:20:26 -0700 (PDT) Received: by mail-io0-f181.google.com with SMTP id g185so95569497ioa.2 for ; Thu, 07 Apr 2016 07:20:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr3479979ioe.38.1460038825663; Thu, 07 Apr 2016 07:20:25 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Thu, 7 Apr 2016 07:20:25 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F27D6E@ESESSMB209.ericsson.se> References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F27D6E@ESESSMB209.ericsson.se> Date: Thu, 7 Apr 2016 10:20:25 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1140b472906316052fe5c765 Archived-At: Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 14:36:27 -0000 --001a1140b472906316052fe5c765 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 7, 2016 at 10:08 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > I'd have to double check the MMUSIC minutes, but if I remember correctly > people did not want to check multiple hashes (point 2). > You should check all the hashes you consider secure and if any one of them matches the DTLS association certificate, accept the media. It cannot not be the strongest hash or all the hashes that must match. Either of those things are too restrictive and can break some scenarios. Just as an example, consider that RTP and RTCP can come from two different sources (devices) which will use different DTLS associations for each component, use different certificates, and potentially support different sets of hash functions. Because of this, the fact that RTP device supports SHA-256 does not mean that RTCP will use it or support it. Regards, _____________ Roman Shpount --001a1140b472906316052fe5c765 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Apr 7, 2016 at 10:0= 8 AM, Christer Holmberg <christer.holmberg@ericsson.com&g= t; wrote:
I'd have to double check the MMUSI= C minutes, but if I remember correctly people did not want to check multipl= e hashes (point 2).

You should check al= l the hashes you consider secure and if any one of them matches the DTLS as= sociation certificate, accept the media.

It cannot= not be the strongest hash or all the hashes that must match. Either of tho= se things are too restrictive and can break some scenarios. Just as an exam= ple, consider that RTP and RTCP can come from two different sources (device= s) which will use different DTLS associations for each component, use diffe= rent certificates, and potentially support different sets of hash functions= . Because of this, the fact that RTP device supports SHA-256 does not mean = that RTCP will use it or support it.

Regards,
_____________
Roman Shpount
=C2=A0
--001a1140b472906316052fe5c765-- From nobody Thu Apr 7 08:09:49 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5518F12D5C8 for ; Thu, 7 Apr 2016 08:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Le5kprWT4jIW for ; Thu, 7 Apr 2016 08:09:42 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8C8D12D5A1 for ; Thu, 7 Apr 2016 07:56:38 -0700 (PDT) X-AuditID: c1b4fb25-f79f86d00000400a-9f-57067524866b Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9F.85.16394.42576075; Thu, 7 Apr 2016 16:56:37 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.248.2; Thu, 7 Apr 2016 16:56:35 +0200 To: Roman Shpount , Justin Uberti References: From: Magnus Westerlund Message-ID: <5706751F.7030009@ericsson.com> Date: Thu, 7 Apr 2016 11:56:31 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM2K7rq5qKVu4wYZPrBZbpwpZTF3+mMVi xoWpzA7MHgs2lXosWfKTyePWlIIA5igum5TUnMyy1CJ9uwSujPNdq5gKXotWLHq+gLmB8ZlA FyMHh4SAicSX82VdjJxAppjEhXvr2boYuTiEBI4wSuzd38gK4SxjlNhxaBsLSJWwgJPEgd29 rCC2iICnxJufi5khiqYzSqxrvcgEMpVZQF3i6uIgkBo2AQuJmz8a2UDCvALaEk+v+YOEWQRU JLrblzGB2KICMRLH351jBLF5BQQlTs58AraKUyBQ4uyBvWwQE+0lHmwFu5NZQF6ieetsZhBb CGhiQ1MH6wRGwVlIumchdMxC0rGAkXkVo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmDYHtzy W3UH4+U3jocYBTgYlXh4FfazhguxJpYVV+YeYpTgYFYS4V2QyRYuxJuSWFmVWpQfX1Sak1p8 iFGag0VJnDc78l+YkEB6YklqdmpqQWoRTJaJg1OqgZFDznXiiXt6t/fL5nx6ftF825Jo+47g jU6+ifd1yu+rOU8Vf7fluNZcAd+5Pz+fldghdPyeY9g/Nfs3udWuhnpnJI+2XPv94ELRFO2q +xoNDI83Ht4Wt88qwtw3R3SdeOqth42KZiriZ9i+xlxIqxOwEIo6rDbNibfwd2pjYGRbv1ls CovgHSWW4oxEQy3mouJEAIsxFX1XAgAA Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] a=rtcp-mux-exclusive vs a=rtcp:0 compression X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 15:09:48 -0000 Den 2016-04-05 kl. 18:36, skrev Roman Shpount: > I have modified the proposed SDP slightly. I have removed IN IP4 0.0.0.0 > from a=rtcp attribute. I cannot find a place that states that a=rtcp is > required when rtcp-mux is used, so I removed a=rtcp from the > rtcp-mux-exclusive examples. RFC 5761 has the following sentence in Section 5.1.1: Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=rtcp:" attribute [10] is also included). So, I would agree that a=rtcp is not mandatory based on RFC 5761, it do results in that the fall back for RTCP is m= port+1. But, as this is intended for the case of not having any fallback. However JSEP do contain text that appears to require that a=rtcp are included. This, may be changed to support the mux-exclusive usage. However, I haven't checked if this requirement is due to trickle ICE. /Magnus Also, since we are shaving bits, I did a > version with SDP attribute named rtcp-mux-only, which is 5 bytes > shorter. So, my results are: > > | port 0 | -exclusive | -only| > --------------------------------------------- > Uncompressed | 1438 | 1462 | 1452 | > Compressed | 716 | 725 | 720 | > > Regards, > > _____________ > Roman Shpount > > On Tue, Apr 5, 2016 at 10:14 AM, Justin Uberti > wrote: > > Minor point for the beauty contest... > > Compressing the attached SDP files (adapted from the examples in > https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-14#section-7.1) > with gzip (default settings) gives the following output: > > | port 0 | -exclusive | > ------------------------------------- > Uncompressed | 1467 | 1487 | > Compressed | 723 | 739 | > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Apr 7 08:13:59 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D4312D90B for ; Thu, 7 Apr 2016 08:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 gXgMLvDPtHc9 for ; Thu, 7 Apr 2016 08:13:57 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3366712D7FA for ; Thu, 7 Apr 2016 08:00:07 -0700 (PDT) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by comcast with SMTP id oBPdaEEji8DPnoBPia1YPR; Thu, 07 Apr 2016 15:00:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460041206; bh=gOPMnkW523fr3W0oPHzHMJoBGL/q0RPwt6fZQQomVdg=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=FMldmV6d8AlucHy1VjuRMHPDgz5SBewRaXLlG5QaZ9kxkL0aVThHUP4WZpsqc0jPf aiQ/9IyRZmWfrs+Yb/R/CB2wbMaIJPU2btJzl8oKtrs0DGnB8dcR33On5rxbtuSElr hPIVJ1FXCkq8s50AGxJN/yYTb6dLt2d8I4MksrgKnm0suTHyJkIwk830S7itZjA/Rn LyyWKqaGGOw3hYUzkZjGpOGV3KEucu4vNz+feZhI4a4/FWxI+YfxTS0HQdKShxKyQd jLxgKtAm3+oarZEt1+o+4eh7s2wAoEQdZ9VM7ahYZthHzmHcka2q3rBkI2IktRpP0A gh4MFlamADYTg== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-07v.sys.comcast.net with comcast id fT051s00A1nMCLR01T054q; Thu, 07 Apr 2016 15:00:06 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u37F04kS032137; Thu, 7 Apr 2016 11:00:04 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u37F031O032134; Thu, 7 Apr 2016 11:00:03 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Martin Thomson In-Reply-To: (martin.thomson@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 07 Apr 2016 11:00:03 -0400 Message-ID: <87twjdtqfg.fsf@hobgoblin.ariadne.com> Archived-At: Cc: jonathan@vidyo.com, mmusic@ietf.org, christer.holmberg@ericsson.com Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 15:13:58 -0000 Martin Thomson writes: > Maybe three pieces of advice are right. > > 1. Implement the strongest hash you can > 2. Check all the hashes you can > 3. Don't accept a session if you can only check weak hashes I'm just now looking at this, but it seems to me that it is sufficient for the receiver of the hashes to check any one hash that it considers to have a sufficiently secure algorithm. If the hash was sent to it, that shows that the sender considers it to be secure enough. (Of course, if it does not receive any hash that it considers secure, the receiver should reject the negotiation.) There doesn't seem to be any reason for the receiver to check more than one sufficiently secure hash. Because it received them, the receiver knows that the sender thinks both hashes are secure, and by hypothesis the receiver thinks they are both secure, so every party to the transaction expects that if one hash is valid, the other one will be. Of course, we could allow the receiver to check multiple hashes if it wishes... Dale From nobody Thu Apr 7 08:15:58 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3CE12D9D2 for ; Thu, 7 Apr 2016 08:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 M6LlAXo4obO3 for ; Thu, 7 Apr 2016 08:15:46 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4AA512D865 for ; Thu, 7 Apr 2016 08:03:43 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id c4so102568932vkb.3 for ; Thu, 07 Apr 2016 08:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=O1aFhActtd3zaAfeHEPGdT40Oq8M26ovU/gjINrTNt4=; b=DwPaf/5Ulrm0GRQJXIX+NnW0eAmv/8ADdE3Di+p95jK8P6rInBxGWCRNSilSQAgrKs Ufqa5t9d6sOompaveeVNfsZBv7JK7lL9+y/FllwWXQ6MRmB5g0Q0PX2MRRfV4ur2jPfo bixQ2Ur1Cpl45ssfwOEeQLHzqeeh2LdEJoU1g2GVgqO5cGzf242b3yGxsHcwW491fy/7 6fUzvtpdbc7FnzdIp+W4DdaEFjyUTA7qxjTf8NJnLjh8Z1gSZ3xMVIrYPsZ1Zrs2NUsM Q6lnjU2jopSZ/9C63Uws6uXoX12Q77B4Y9I3xxVjvw8F0ri9yveQoB/+bzjIcdKpCSn6 77Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=O1aFhActtd3zaAfeHEPGdT40Oq8M26ovU/gjINrTNt4=; b=fNuoitBgXMktBYVAGgui9+m+vdRVvaqNBS5shgBYupCDFfv+BstUhA1SRUnQLY7MQk VG5sRrhS28Zt3xWKMoNEXiqpcV+CkRBtIe05thBiOHZ/LRtQ9gP446vohHA7VuSdb1vC jYmQMFAc4UOGK48nik45nhIuIss3Q9BUJXhamHG3TJdAZ2Xv3lUXVmK92JBdAiryakz8 VMv7+wzoIUqzv67l/MJ0PDlfMeeMV5XxK/RIL6QvaKNscPlXGUQutz9vmnQr9GDoAk4Q M+/E1htoB/wDTRGkv88uOXpmR62CRw9OyqrLmdKClIQQ5R9bUqBxMk3VIvfGj5k/rB/2 HQfQ== X-Gm-Message-State: AD7BkJJNPvVDrljIw2plEkIooQGhK2cuwn9EgZTwOOOPaWFsPxcJWzSh4jF3+Vh/hbhW4pH/eaHd8ojyTwqP9RYu X-Received: by 10.31.11.201 with SMTP id 192mr1603902vkl.135.1460041422620; Thu, 07 Apr 2016 08:03:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.67.164 with HTTP; Thu, 7 Apr 2016 08:03:02 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Thu, 7 Apr 2016 08:03:02 -0700 Message-ID: To: Tim Panton Content-Type: multipart/alternative; boundary=001a114551525aa568052fe662ec Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 15:15:49 -0000 --001a114551525aa568052fe662ec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 5, 2016 at 2:52 AM, Tim Panton wrote: > > On 5 Apr 2016, at 03:06, Justin Uberti wrote: > > > > On Mon, Apr 4, 2016 at 8:39 AM, pfh wrote: > >> >> On 4 Apr 2016, at 14:10, Eric Rescorla wrote: >> >> Hi folks, >> >> I wanted to call your attention to a draft I just published with a >> possibly stupid >> idea. >> >> https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 >> >> A nontrivial fraction of call setup time in WebRTC is the DTLS handshake= . >> This document describes how to piggyback the first few handshake message= s >> in the SDP offer/answer exchange, thus reducing latency. >> >> >> It strikes me we could get the same reduced latency benefits by >> piggybacking on ICE >> rather than SDP, e.g. embedding the DTLS packet as data in a new STUN >> attribute type. >> >> The downside of piggybacking on the SDP is that you are increasing the >> trust you have to place in the >> signalling server undermining the elegant decoupling we have at the >> moment between signalling and >> media. (The SDES issues of logging keys in the web servers apply to the >> public certs as well). >> > > I don't think the logging issue applies here. Only the public key would b= e > logged, and it's already transmitted in cleartext during a normal DTLS > handshake (it's a public key, after all). > > > True, but over a different path. > > >> It also significantly clutters the SDP (even more) ! >> > > Please see Jonathan Lennox's comment about garbage piles. I think the onl= y > truly unattractive part here is the fact that the messages will need to b= e > base64ed, resulting in minor blowup. But that seems like a reasonable > downside for 1+ RTT upside. > > > Just when the WebRTC NG was freeing us from Offer/Answer and SDP=E2=80=A6= . > > Sigh. > > =E2=80=8BThe general idea here is "put the beginning of the crypto handshak= e in the signaling"=E2=80=8B. That's not tied to SDP. WebRTC NG could easily do th= e same thing without SDP. > > > >> As you point out, it weakens the usefulness of longer term certs, which >> would be a major nuisance IMHO. >> >> Tim. >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a114551525aa568052fe662ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 5, 2016 at 2:52 AM, Tim Panton &= lt;tim@phonefrom= here.com> wrote:

On 5 Apr 2016, at 03:06, Justin Uberti <juberti@google.com> wrote:


On Mon, Apr 4, 2016 at 8:39 AM, pfh <tim@phonefromhere.com<= /a>> wrote:


Hi folks,<= div>
I wanted to call your attention to a draft I just publis= hed with a possibly stupid
idea.

https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00

A nontrivial fraction of call setup time in WebRTC is= the DTLS handshake.
This document describes how to piggyback the= first few handshake messages
in the SDP offer/answer exchange, t= hus reducing latency.

<= div>It strikes me we could get the same reduced latency benefits by piggyba= cking on ICE
rather than SDP, e.g. embedding the DTLS packet as d= ata in a new STUN attribute type.

The downside of = piggybacking on the SDP is that you are increasing the trust you have to pl= ace in the
signalling server undermining the elegant decoupling w= e have at the moment between signalling and=C2=A0
media. (The SDE= S issues of logging keys in the web servers apply to the public certs as we= ll).

I don't think th= e logging issue applies here. Only the public key would be logged, and it&#= 39;s already transmitted in cleartext during a normal DTLS handshake (it= 9;s a public key, after all).=C2=A0

True, but over a different path.=C2=A0
<= span class=3D"">

It also sig= nificantly clutters the SDP (even more) !

Please see Jonathan Lennox's comment about garbage pil= es. I think the only truly unattractive part here is the fact that the mess= ages will need to be base64ed, resulting in minor blowup. But that seems li= ke a reasonable downside for 1+ RTT upside.

Just when the WebRTC NG was freeing us fro= m Offer/Answer and SDP=E2=80=A6.

Sigh.


= =E2=80=8BThe general idea here is "put the beginning of the crypto han= dshake in the signaling"=E2=80=8B.=C2=A0 That's not tied to SDP.= =C2=A0 WebRTC NG could easily do the same thing without SDP.=C2=A0
=C2=A0

<= br>

As you point out, it weakens the usefulness of lo= nger term certs, which
would be a major nuisance IMHO.
=
Tim.


______________________________= _________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb




_____________________________= __________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


--001a114551525aa568052fe662ec-- From nobody Thu Apr 7 08:29:05 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E84512D0FD for ; Thu, 7 Apr 2016 08:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 t5Ajggru-bVu for ; Thu, 7 Apr 2016 08:28:59 -0700 (PDT) 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 ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC3612D5C8 for ; Thu, 7 Apr 2016 08:21:36 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by comcast with SMTP id oBhRaP37GnIc7oBkVaNNww; Thu, 07 Apr 2016 15:21:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460042495; bh=cauR6ceFtPXUgAGkjoaTKJzDIZuHx1rt6ELN3vJdrl4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=QXNeiNZo+VKQ8LQcc1QXnEkzK2wlkJkYtmmjv2ET3eO8D2qmiWfdTQAIllWbNba3X RMgWNba47EJpZcp5sSSK0u6kBI5D1brYYreFeDLlwOydoPqA3DeGQVP445ckxfg5P9 WHaT9LjkRavvU9naj20qTzQSRO6eUI84AI84oSTCeUyOhi7BSpRdr7mhO3wRxPZZXu 4ItU7r0BgpslsgMHexMjB8a7NHO+26Yx5YdGR4ZC0YaR9AFsMtFafU+BlXqsqNDsA9 VZylhAKnlNKb7O5yCJWIjYdUNl/yjM72UCn6Ta2Jr7bJ++RxUA66LsY72Rnhz1dX5m Bp2br3CZVCC/g== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-18v.sys.comcast.net with comcast id fTMb1s0043KdFy101TMbWi; Thu, 07 Apr 2016 15:21:35 +0000 To: mmusic@ietf.org References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <57067AFE.9070704@alum.mit.edu> Date: Thu, 7 Apr 2016 11:21:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 15:29:05 -0000 On 4/7/16 10:06 AM, Martin Thomson wrote: > On 7 April 2016 at 10:35, Christer Holmberg > wrote: >>> If we do this, it removes some of the questions about “do you need to verify a fingerprint for every >hash algorithm, or only one.” >> >> What about saying that one MUST match on the strongest hash received? > > Maybe three pieces of advice are right. > > 1. Implement the strongest hash you can > 2. Check all the hashes you can If you check the strongest hash you can and it succeeds, then what is the point of checking any others? The one check should be sufficient if there is only one stream. It is a bit more complex if there are multiple streams (e.g., RTP and RTCP). How about: 1) implement as many as you can of hashes you consider strong enough. 2) for all the streams you are originating: include fingerprints using all the hashes you support. (Or is it ok to include fewer?) 3) for streams you are receiving: 3.1) discard any fingerprints using hashes you don't support, and any that you consider too weak to be trusted. 3.2) sort the remaining fingerprints, strongest hashes first. 3.3) for each stream, check fingerprints from the list in order until you find one that matches. Reject the session if none match. Thanks, Paul > 3. Don't accept a session if you can only check weak hashes > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Thu Apr 7 12:09:03 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39B012D6C1 for ; Thu, 7 Apr 2016 12:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 al082j8dTz0G for ; Thu, 7 Apr 2016 12:09:00 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAAE712D6BE for ; Thu, 7 Apr 2016 12:08:59 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id 2so105615316ioy.1 for ; Thu, 07 Apr 2016 12:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=PrAh4GaObuA371b80okJ0JDcj2rl/r41biJ6xRdTyn4=; b=ykbn32G6z0X+A3ygweJTfwkTKiZcbP+mIV4WPBywlTwNR/kFRt2ZphLOp0fr50DK1m XP42Oj4OR10tMnkqL/nc9bd7yXXl3F7kgmdH5jqjbfpbAeulpCxfH4y/8QRFzFiBiqS5 Da6Nqd5maJj+WwM3w4YtWgfqKkUOOC0IU6VU5TOlN4EXMRI0oCjjlnjTQl4JugB8Vh92 K9c1TNQWabsvAekBF97JRUVxNXo+MfO+8mTgzoXRgKQu1yPiAtsDGcgsKqdzu+9YCTxR 3S22Zgi33pEzbzh+aJb8dxj4eKBlkmyHQWGSVd6osSjYht5dVBg3GP0WHt2Oyg/zjWmo dpSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=PrAh4GaObuA371b80okJ0JDcj2rl/r41biJ6xRdTyn4=; b=M1WfiIPIp53RFljZTQHV/ZDvlhKlrIivAfkbPSFVeYgUvAhjAB+Zu7yvzEiIfJi5hy suger4OuuQiRTiftkaDy3ZXfF18t/fY4fuLwNdjdtngpEg/OQ74JAe75uH2JHyL5qu6b MZiylTIa3K0abR8aL9MHcTAEgbDBY0iBRgV8MRHIwHuz7KGCMxthMmWF1/FygayYXG2I GSTXFaWdmR2iCSFeIMb3WSQvpQx3iswNroua86Z7PPoq8V5Gnaw2XdGkPwXKgVZ7i6GE BeW8YtY6iMBbaC/Avkbbp0hxpMRHS8C6Cl4q87B5n6BbPVbcpQ+Q1i1PYrfRD758F7Pl S1kg== X-Gm-Message-State: AD7BkJIhmSWm7oSYO8sl4Y96DGuIT8QbyNy0QwaXPfFIZPuAPvOF7QF70vE2Is3bi0bU8A== X-Received: by 10.107.164.205 with SMTP id d74mr5239979ioj.80.1460056138944; Thu, 07 Apr 2016 12:08:58 -0700 (PDT) Received: from mail-io0-f182.google.com (mail-io0-f182.google.com. [209.85.223.182]) by smtp.gmail.com with ESMTPSA id h184sm4312211ioh.2.2016.04.07.12.08.58 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 12:08:58 -0700 (PDT) Received: by mail-io0-f182.google.com with SMTP id o126so83247893iod.0 for ; Thu, 07 Apr 2016 12:08:58 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.30.71 with SMTP id e68mr5202924ioe.145.1460056137976; Thu, 07 Apr 2016 12:08:57 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Thu, 7 Apr 2016 12:08:57 -0700 (PDT) In-Reply-To: <57067AFE.9070704@alum.mit.edu> References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <57067AFE.9070704@alum.mit.edu> Date: Thu, 7 Apr 2016 15:08:57 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a1140d71e74f510052fe9cfe1 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 19:09:03 -0000 --001a1140d71e74f510052fe9cfe1 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 7, 2016 at 11:21 AM, Paul Kyzivat wrote: > If you check the strongest hash you can and it succeeds, then what is the > point of checking any others? If you check any hash that you consider secure and it succeeds, you do not need to check any others. There is no difference if it is the strongest or just the hash that is strong enough. > The one check should be sufficient if there is only one stream. It is a > bit more complex if there are multiple streams (e.g., RTP and RTCP). > > How about: > > 1) implement as many as you can of hashes you consider strong enough. > > 2) for all the streams you are originating: > include fingerprints using all the hashes you support. > (Or is it ok to include fewer?) > It might be ok to include fewer but I cannot think of a single reason why you would do this. 3) for streams you are receiving: > > 3.1) discard any fingerprints using hashes you don't support, > and any that you consider too weak to be trusted. > > 3.2) sort the remaining fingerprints, strongest hashes first. > There is no reason to sort. This will not make hash check any more secure. If a hash you consider secure is compromised you will just get false positive slightly later. There is probably a reason to sort hashes based on the amount of resources it will take for you to check them, with easiest to check first in order to optimize the hash checking process. This will likely sort the hashes weakest first. 3.3) for each stream, check fingerprints from the list in order > until you find one that matches. > Reject the session if none match. > Once again, if any match accept the session. If none match, reject. Checking order does not matter and will not affect overall security. Regards, _____________ Roman Shpount --001a1140d71e74f510052fe9cfe1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 7, 2016 at 11:21 AM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:
If you check the strongest hash you can and it succeeds, then wha= t is the point of checking any others?

If = you check any hash that you consider secure and it succeeds, you do not nee= d to check any others. There is no difference if it is the strongest or jus= t the hash that is strong enough.
=C2=A0
= The one check should be sufficient if there is only one stream. It is a bit= more complex if there are multiple streams (e.g., RTP and RTCP).

How about:

1) implement as many as you can of hashes you consider strong enough.

2) for all the streams you are originating:
=C2=A0 =C2=A0include fingerprints using all the hashes you support.
=C2=A0 =C2=A0(Or is it ok to include fewer?)
=C2=A0
It might be ok to include fewer but I cannot think of a single reas= on why you would do this.

3) for strea= ms you are receiving:

3.1) discard any fingerprints using hashes you don't support,
=C2=A0 =C2=A0 =C2=A0and any that you consider too weak to be trusted.

3.2) sort the remaining fingerprints, strongest hashes first.
=C2=A0
There is no reason to sort. This will not make has= h check any more secure. If a hash you consider secure is compromised you w= ill just get false positive slightly later. There is probably a reason to s= ort hashes based on the amount of resources it will take for you to check t= hem, with easiest to check first =C2=A0in order to optimize the hash checki= ng process. This will likely sort the hashes weakest first.

<= /div>
3.3) for each stream, check fingerprints from the lis= t in order
=C2=A0 =C2=A0 =C2=A0until you find one that matches.
=C2=A0 =C2=A0 =C2=A0Reject the session if none match.
=
Once again, if any match accept the session. If none match, = reject. Checking order does not matter and will not affect overall security= .

Regards,
_____________
Roman Shpount
=C2=A0
--001a1140d71e74f510052fe9cfe1-- From nobody Thu Apr 7 12:27:26 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA71812D1C0 for ; Thu, 7 Apr 2016 12:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 RaMWxprsK6oj for ; Thu, 7 Apr 2016 12:27:23 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45F0312D1F0 for ; Thu, 7 Apr 2016 12:27:23 -0700 (PDT) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by comcast with SMTP id oFZza4D1bsK9moFaMaa3aA; Thu, 07 Apr 2016 19:27:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460057242; bh=PHYKqy5/YK9Ow5FigO+OvU84Om4N2Wa3+BpBYXnNsaU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=vKGYgtAcaaKZo0i3pOubavhl8G4yd1TZuoMFbsU+/xWK5bvayndEmYDj53PMrSKB1 b26ajxDqs84S/woJioiLRaCCYtF07al1p8TPJoRswnh4UsSxb9yWz+CTl93kUPjO3I uxhz+k0IVolUZMHVAC/R4YfCXCc3kzDkFtPI26p0Oz6lXBUq5g1jtuKU6ondBK2934 jGh9Tq85kuAYyTjFJJFq7SS3erXPIpK+I+/1zRM6rmdIc5hL/N6+cczZ1GIuS3vQGs OetpgIHj/Aere4SO1omvYBOAv087mjOBvlRnsyV7q+5DdVl4l2XKeiFK3VBPD3GWv+ dANKJ8BJGrCKQ== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-10v.sys.comcast.net with comcast id fXTN1s0013KdFy101XTNEy; Thu, 07 Apr 2016 19:27:22 +0000 To: Roman Shpount References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <57067AFE.9070704@alum.mit.edu> From: Paul Kyzivat Message-ID: <5706B499.9030209@alum.mit.edu> Date: Thu, 7 Apr 2016 15:27:21 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 19:27:24 -0000 On 4/7/16 3:08 PM, Roman Shpount wrote: > On Thu, Apr 7, 2016 at 11:21 AM, Paul Kyzivat > wrote: > > If you check the strongest hash you can and it succeeds, then what > is the point of checking any others? > > > If you check any hash that you consider secure and it succeeds, you do > not need to check any others. There is no difference if it is the > strongest or just the hash that is strong enough. > The one check should be sufficient if there is only one stream. It > is a bit more complex if there are multiple streams (e.g., RTP and > RTCP). > > How about: > > 1) implement as many as you can of hashes you consider strong enough. > > 2) for all the streams you are originating: > include fingerprints using all the hashes you support. > (Or is it ok to include fewer?) > > It might be ok to include fewer but I cannot think of a single reason > why you would do this. > > 3) for streams you are receiving: > > 3.1) discard any fingerprints using hashes you don't support, > and any that you consider too weak to be trusted. > > 3.2) sort the remaining fingerprints, strongest hashes first. > > There is no reason to sort. This will not make hash check any more > secure. If a hash you consider secure is compromised you will just get > false positive slightly later. There is probably a reason to sort hashes > based on the amount of resources it will take for you to check them, > with easiest to check first in order to optimize the hash checking > process. This will likely sort the hashes weakest first. If everybody did this, and the easiest to check one is compromised, and used by a MiTH to inject a bogus cert that matches that nobody might notice. Isn't that undesirable? Thanks, Paul > 3.3) for each stream, check fingerprints from the list in order > until you find one that matches. > Reject the session if none match. > > > Once again, if any match accept the session. If none match, reject. > Checking order does not matter and will not affect overall security. > > Regards, > _____________ > Roman Shpount From nobody Thu Apr 7 12:31:50 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8C512D149 for ; Thu, 7 Apr 2016 12:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 pQ1XlrOSlLrp for ; Thu, 7 Apr 2016 12:31:47 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5513A12D0EF for ; Thu, 7 Apr 2016 12:31:47 -0700 (PDT) Received: by mail-ig0-x234.google.com with SMTP id g8so79639144igr.0 for ; Thu, 07 Apr 2016 12:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=EUeTezQuiP00fQ3Jvi/1Jkty2gEtd46sT7Toda7QeBg=; b=yrN0PXZ/X+u4Q3ihDnl3/S8499R9B8fh+hYijzeFsXDm6AouLL58alhfYWfAuNzXgO qlTtorHnpWMeQjjoBxqWsaVAglmBMaoTSEkMt/SWxT3aeafmt9jxZS9paos1RTV7hEuz eaYFQOUga1CQJyKSIBL46lDpg88pE0faA0LPagkRUgGr5o/utRgS0BLJfKY6SKA9Lx6U b3nnkBfYTsbuykWk41j5XUBWanZ79yMb14nCROnPJGVN7yYsJ7HLTJTl9DvwYiJjO7OL dhPZUtodGA4op50AN8fRkkl5jbVlbvLDPH6Fx1tvdAwgve7cjT6BbD0Uq/U3xXwI3hhe E25w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=EUeTezQuiP00fQ3Jvi/1Jkty2gEtd46sT7Toda7QeBg=; b=axj6XA9CvDpw9AyKw4g5PuC+Hzj9YrGEW+39xcGTdB6I5Wk0CYnpnTEbgGCo4sOESK jkzKBcxqXWl+GO69megSbvpciiDPsQ9YyBPfN1LQyFCw24wKxhNRbxja+eDFV1BNmjcx ogYbZTibnsDjDmlTylP3GwFrfpZ2VwrWeUPKm8ghdCMXG5ZPX3fS/Uw+WCq3b0gRZdTN +6UHs6rodAm0XIsOgrKB/PXHBSHXcTldbTK8kFe/WbPWraRNbFKSCmr/WaLf2Alxe41b t1x4sXudRA2SYJeDgqZ1suTuqOl+ODhew8DizBE2sFYpsaskuWx/DrGIelH6jfsKHALF D8Tw== X-Gm-Message-State: AD7BkJJMWd39j8lwIY3Sv6pKlWMAlUZmmtrK5l30nAKLylZHYvVL2s8faR0eEE/0A7OA0Q== X-Received: by 10.50.43.164 with SMTP id x4mr5152651igl.56.1460057506590; Thu, 07 Apr 2016 12:31:46 -0700 (PDT) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com. [209.85.223.174]) by smtp.gmail.com with ESMTPSA id e75sm4366677ioj.19.2016.04.07.12.31.46 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 12:31:46 -0700 (PDT) Received: by mail-io0-f174.google.com with SMTP id g185so106336560ioa.2 for ; Thu, 07 Apr 2016 12:31:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr4826269ioe.38.1460057505815; Thu, 07 Apr 2016 12:31:45 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Thu, 7 Apr 2016 12:31:45 -0700 (PDT) In-Reply-To: <5706B499.9030209@alum.mit.edu> References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <57067AFE.9070704@alum.mit.edu> <5706B499.9030209@alum.mit.edu> Date: Thu, 7 Apr 2016 15:31:45 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a1140b472fcac41052fea20fc Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 19:31:49 -0000 --001a1140b472fcac41052fea20fc Content-Type: text/plain; charset=UTF-8 On Thu, Apr 7, 2016 at 3:27 PM, Paul Kyzivat wrote: > On 4/7/16 3:08 PM, Roman Shpount wrote: > >> There is no reason to sort. This will not make hash check any more >> > secure. If a hash you consider secure is compromised you will just get >> false positive slightly later. There is probably a reason to sort hashes >> based on the amount of resources it will take for you to check them, >> with easiest to check first in order to optimize the hash checking >> process. This will likely sort the hashes weakest first. >> > > If everybody did this, and the easiest to check one is compromised, and > used by a MiTH to inject a bogus cert that matches that nobody might > notice. Isn't that undesirable? > This is why you should discard hashes that you consider too weak. After you done this, since any single hash match is sufficient, it does not matter in what order the hashes are checked. If the weak hash is present, the session will be accepted. _____________ Roman Shpount --001a1140b472fcac41052fea20fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Apr 7, 2016 at 3:27= PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 4/7/16 3:08 PM, Roman Shpount wrote:
There is no reas= on to sort. This will not make hash check any more
<= div>
secure. If a hash you consider secure is compromised you will just get
false positive slightly later. There is probably a reason to sort hashes based on the amount of resources it will take for you to check them,
with easiest to check first=C2=A0 in order to optimize the hash checking process. This will likely sort the hashes weakest first.

If everybody did this, and the easiest to check one is compromised, and use= d by a MiTH to inject a bogus cert that matches that nobody might notice. I= sn't that undesirable?

This is why = you should discard hashes that you consider too weak. After you done this, = since any single hash match is sufficient, it does not matter in what order= the hashes are checked. If the weak hash is present, the session will be a= ccepted.
_____________
Roman Sh= pount
=C2=A0
--001a1140b472fcac41052fea20fc-- From nobody Thu Apr 7 12:33:39 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E70212D0EF for ; Thu, 7 Apr 2016 12:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 J4qD8mxofSgL for ; Thu, 7 Apr 2016 12:33:37 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D963F12D0BA for ; Thu, 7 Apr 2016 12:33:36 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id q128so106302681iof.3 for ; Thu, 07 Apr 2016 12:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=/JBY+a7stAUGkEkSEhllD/DFTwJZp45D36fd2eJtfuE=; b=SIy3BblP4FzqS1eHHj6nBuxN1dk48h9ieFk3iFhFTipPIC07ph26ushPnZE0ZdF20H s88/yLwXqRJqs1aKPTr5+FKdQokfwAXBjKYwpuK8onYwnFL54LvZ7H7gve7DuuqcOpTu RssdhdJvRmPyHHQL/afxGIE/kSFynbjrrpttkJ9uIwuRzFsjBJIPridUB1dciPUNzwKD tX0wb1skKNAZm4RcBNMmqVIXot7QwltTVHwyom1QSatIxMBi0bEWXB9iZDVirPfJ9Vrq kqin0kdQCj7J9oI27amnFj4TW9cXFwlnpI0Zgohcp6MWqLfGJiKmMKxDp5G+CxgF22O3 xwOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/JBY+a7stAUGkEkSEhllD/DFTwJZp45D36fd2eJtfuE=; b=lnmpGGfPhFloC3ndtcw1o2A3eITOclaFvYfBptp7+SRhd2ITPDKawvqUw0xKsf7N5k ZWMqaZTuX0J6bp7ux+zivGxWsgib3sHYUYyb8pkSGenrvYfFjzEXRS3vQRIWoY6RSfib jfWEQiWpYp6N4DYDYX31L3HCxSQpR7Xsezda2bOYYCqbxlsSh3bB4DzRmgHNYbf9DQgz yfzBMja7FsfCnLjoVTPy38WTSHbqrNJqIU2fELvTmwp6aNqVP13JmK4Z2v0oXPiVMyiS DIr4J/qgsPvCs9F7w7xu/Rp3wFVJ0M6Y7oSN3imGV++GIvPQiesgVeyJjDseR8bgYUiY dEeg== X-Gm-Message-State: AD7BkJLZb49TboHu1C/Sb/kEJ3MVslPyoEtaYSpxMohh2LM1jAE/DJqnv8mjgGE477q7/EMHJVKiF7RK/DIb3A== MIME-Version: 1.0 X-Received: by 10.107.34.139 with SMTP id i133mr4845277ioi.108.1460057616190; Thu, 07 Apr 2016 12:33:36 -0700 (PDT) Received: by 10.36.43.5 with HTTP; Thu, 7 Apr 2016 12:33:36 -0700 (PDT) In-Reply-To: References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <57067AFE.9070704@alum.mit.edu> <5706B499.9030209@alum.mit.edu> Date: Thu, 7 Apr 2016 16:33:36 -0300 Message-ID: From: Martin Thomson To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 19:33:38 -0000 On 7 April 2016 at 16:31, Roman Shpount wrote: > This is why you should discard hashes that you consider too weak. After you > done this, since any single hash match is sufficient, it does not matter in > what order the hashes are checked. If the weak hash is present, the session > will be accepted. I would argue that you should check all hashes that you support and are present. Then, you can be protected against weaknesses that you aren't aware of. From nobody Thu Apr 7 12:55:05 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E5612D17D for ; Thu, 7 Apr 2016 12:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 EpQFmzTRviiU for ; Thu, 7 Apr 2016 12:55:01 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B53D12D0BA for ; Thu, 7 Apr 2016 12:55:01 -0700 (PDT) Received: by mail-ig0-x234.google.com with SMTP id ui10so80150422igc.1 for ; Thu, 07 Apr 2016 12:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ZK9x9dvmrMuVQUJJDWk4VEH1PQ8JiGlM6U5XT/6aCb8=; b=oWTFpPJfgnI9xepF7byiRVzjEstvt3jWyXghJoPd8tgN6m3Q797f7D2dgvrEBCef1/ B7CxEeMGEtIuJ/rJ4jbpB02gQ9SOCD8Nmu/wtySciRxujkovVYHZfOOoIPJ7qmg1beAZ o9X17QZEmck2OcwWNKg9X4B/ulV9YUZRWoAj7OCRKP5VeZO9KSm+iDKy7kx2yYlj8JvE JqGuV/nMDgIVt6ibJAuLD238/rFClGGpAqrloSaSk9NZc6Qg4S8XD3EHZ+yOuCu6WH4P quEo0EbOjKRpK7Te7R4aY3Vev8C+d3bofSZeFsyd95CCYjSjYcE+23mzjY89keRuXhlu SwFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ZK9x9dvmrMuVQUJJDWk4VEH1PQ8JiGlM6U5XT/6aCb8=; b=mN6sDCfBL1xLnOpCcxz8W5TF2AyxQHH3AqaweJfsgocxZ6VnRfU2FSAL0bp54uJfO1 E5QCaUCV3BIK4ppPCF3Q8fe/etLLem+1yJ4p9IQlzxikVPC9DlWK3Iu/OSDoQ2u1WYWh 9lWr0P4tZrUaeZnKi1T6l8AivP7EH580CryIkcd7h7/7aUSlN0OdOf1Dap12JI/x+TCs +hgU/I3yWU/PDl4B1RPD6zmDiXr2hM/3nr2NzhM5Iky/x+cdU05JgIi51CBtOWJrZpRV vkxo0Tziz3i6CgLAd/R6jbTcr2vlRakARidQMj4n4qfwzZcVXdcQwX6pMSR+OU4FnbcU HMZQ== X-Gm-Message-State: AD7BkJIi5IzbkOpP8s6l8L2QnE6vDsiJSQwI+bZ/Ce/s0t6g2MbuuakgEiJaFBDCBYg4CA== X-Received: by 10.50.29.73 with SMTP id i9mr5709913igh.32.1460058900745; Thu, 07 Apr 2016 12:55:00 -0700 (PDT) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com. [209.85.223.169]) by smtp.gmail.com with ESMTPSA id in6sm12349047igb.0.2016.04.07.12.55.00 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 12:55:00 -0700 (PDT) Received: by mail-io0-f169.google.com with SMTP id o126so84699829iod.0 for ; Thu, 07 Apr 2016 12:55:00 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr4903182ioe.38.1460058899829; Thu, 07 Apr 2016 12:54:59 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Thu, 7 Apr 2016 12:54:59 -0700 (PDT) In-Reply-To: References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <57067AFE.9070704@alum.mit.edu> <5706B499.9030209@alum.mit.edu> Date: Thu, 7 Apr 2016 15:54:59 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1140b472135c95052fea7427 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 19:55:03 -0000 --001a1140b472135c95052fea7427 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 7, 2016 at 3:33 PM, Martin Thomson wrote: > On 7 April 2016 at 16:31, Roman Shpount wrote: > > This is why you should discard hashes that you consider too weak. After > you > > done this, since any single hash match is sufficient, it does not matter > in > > what order the hashes are checked. If the weak hash is present, the > session > > will be accepted. > > > I would argue that you should check all hashes that you support and > are present. Then, you can be protected against weaknesses that you > aren't aware of. > Let me try to explain this again why this will not work. Consider that RTP and RTCP can come from two different sources (devices) which will use different DTLS associations for each component, use different certificates, and potentially support different sets of hash functions. Because of this, the fact that RTP device supports SHA-256 does not mean that RTCP will use it or support it. Regards, ______________ Roman Shpount --001a1140b472135c95052fea7427 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 7, 2016 at 3:33 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
=
On 7 April 2016 at 16:31, Roman Shpount &= lt;roman@telurix.com> wrote: > This is why you should discard hashes that you consider too weak. Afte= r you
> done this, since any single hash match is sufficient, it does not matt= er in
> what order the hashes are checked. If the weak hash is present, the se= ssion
> will be accepted.


I would argue that you should check all hashes that you support and<= br> are present.=C2=A0 Then, you can be protected against weaknesses that you aren't aware of.

Let me try to expl= ain this again why this will not work. Consider that RTP and RTCP can come from two different source= s (devices) which will use different DTLS associations for each component, = use different certificates, and potentially support different sets of hash = functions. Because of this, the fact that RTP device supports SHA-256 does = not mean that RTCP will use it or support it.=C2=A0

Regards,
______________
Roman Shpount

--001a1140b472135c95052fea7427-- From nobody Thu Apr 7 13:09:48 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BC112D0F7 for ; Thu, 7 Apr 2016 13:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qEIB0q_3SLC8 for ; Thu, 7 Apr 2016 13:09:46 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E97FB12D0A8 for ; Thu, 7 Apr 2016 13:09:42 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id o126so85173769iod.0 for ; Thu, 07 Apr 2016 13:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=++08NCJRKmjdIdLPTci9PV2aGCm273blPGV/XGf3QSs=; b=Z6+eP+ckXnw/Aqpztv9VZ51FKqo2skYNpTz8NgxShMoa5D/vXOftFGlY9UyhEUR7Yk HNgUEhkgp2/bOedaL/P3vJZD/86wWYGvEGh5kD+Geu/lFomiorrNhCMXyPMEYfIsmsKt moXmt3tuxnmSGu76RV+qh2p/+9tbuxTlozyHOoEtrq+mqrbOowLGYhRDZ2F9aW38X7pz I8f/VVpQyQdPymWaow0OhltPaeP9H7xfzOYPLy2iDgHjymt9XhL2Cn+SgpLo9/HNMEfT 3rxLD2WCnoaAVFb+Cuwp0OYLpcdzRkAWB5TSB6eHHqv73cEq/NYyTPSqIDzofdb6FwvU bs2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=++08NCJRKmjdIdLPTci9PV2aGCm273blPGV/XGf3QSs=; b=EgoO9t1j9is0ia70XXRM2NnqfIhUEAzzbw9gU7I9yax7eX7BJi8rQm0fQzsEvdrE2s vkFVa7tHg0uY1xtAlm9O+gxglv0qxlar7BNH4xmlClTWoPrKeV+QpvJkndIwUYRfKE41 CFM1kOIJ3Zq3OccWPAmE5CKMj0g6moy6DqQTHeyCluwXM9/M8ytXIgCy8pcS5HSL+cM7 aTv2Oi5kk7uXBiFK78TsOiz28jt9+etOrs/AGnJ09NppcviTr2/pR1lY5Cg/skPahdGc hdNLOHDiy2wxC/0dANcKnTQDD6lklZttPdcv3JuLMsV5HUElXpl7G8ha3IJj8Tizbl0D xB2w== X-Gm-Message-State: AD7BkJLEne6fdiGILszO/58GNBjVXSGDWhw+j4SVRQWG9dJCRrvlzMb/YZSsq+hwRZuWsMd+RW2HavCq2QfNFg== MIME-Version: 1.0 X-Received: by 10.107.166.72 with SMTP id p69mr5491876ioe.100.1460059782316; Thu, 07 Apr 2016 13:09:42 -0700 (PDT) Received: by 10.36.43.5 with HTTP; Thu, 7 Apr 2016 13:09:42 -0700 (PDT) In-Reply-To: References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <57067AFE.9070704@alum.mit.edu> <5706B499.9030209@alum.mit.edu> Date: Thu, 7 Apr 2016 17:09:42 -0300 Message-ID: From: Martin Thomson To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:09:47 -0000 On 7 April 2016 at 16:54, Roman Shpount wrote: > Let me try to explain this again why this will not work. Consider that RTP > and RTCP can come from two different sources (devices) which will use > different DTLS associations for each component, use different certificates, > and potentially support different sets of hash functions. Because of this, > the fact that RTP device supports SHA-256 does not mean that RTCP will use > it or support it. How is that relevant? If the RTCP endpoint doesn't support X, then it uses what it can. From nobody Thu Apr 7 13:55:08 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274B812D135 for ; Thu, 7 Apr 2016 13:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 mXWkgLDboWUH for ; Thu, 7 Apr 2016 13:55:05 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C10812D16F for ; Thu, 7 Apr 2016 13:55:05 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id 2so108915742ioy.1 for ; Thu, 07 Apr 2016 13:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=4UGFasJiCW6tg/R9u1q4XQXPLVIvyiqeaz45iZtzvjI=; b=PcwSJ6JFaSyKNDK7TRPDzo0x7JL9dPbTUR31icdtfgPQLzTkt7AUb42tpil7BuiFWB rKC0cpmhSYGvpCpnZOkgG2RA8aJ8Y1W+7sFxU7fCV3Hx3oYyY4lgLroM0vo6bx5LilQc yAA0opQ57ujX9/Uyjn4hXSPPHs7c0gmGnj+DSYsUhHxry5XkK97Uul1A6/6kOwSVa1Tx uTD05JUC13d2mVk7VwX5M7ixf5rCpx0B8FymqmWxfrYsUFCOx9Eip5LoEfD/238ZQq19 rS6eQo4i+o4pxIHbTL4mmzYpPG7+ya/OVhdEGQMr6ohj6HN7UejEUpcQOsM3r7dCz1bj QlMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=4UGFasJiCW6tg/R9u1q4XQXPLVIvyiqeaz45iZtzvjI=; b=Rxn6Jm7c4KJz2ZL1/c6/28hDV06IuqUHgFqcjTikUm1EnwrSnRoG2RnLxFTrk6Fay2 PboMS6+BsRDgCvj5LJHfU9K5VzETwyczXOibfrWhOW6KEOnfcm6OEh5mDDI6FK6FlZQU PFzu/5aXq0Kuo/Fm+5Kdt2n4EUKX6EmWzT4WecsilrGr6omKJ/9K9VL/0dJsDhWcB2mt IuBmdO8VcfVnn/zsBI0Ty+L4O2KfMmxQ7iudT8UdMdXNw4ubEiLQ48crsS+oUOQFMK2P nIOcfbg0PRoBPmJTEVe2c/+hFObNakefEYvU28ysfLqGQYVOw21DI9YiLDrM7WRxwxQk Nv0w== X-Gm-Message-State: AD7BkJK6ghXfvZacQmdp0ORK8WZEPBGGBXKFKkY4HBufIgO6FNTu8QDq6wI0OsVFKx9cog== X-Received: by 10.107.10.167 with SMTP id 39mr6420128iok.152.1460062504357; Thu, 07 Apr 2016 13:55:04 -0700 (PDT) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com. [209.85.223.171]) by smtp.gmail.com with ESMTPSA id ip3sm4495562igb.14.2016.04.07.13.55.03 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 13:55:03 -0700 (PDT) Received: by mail-io0-f171.google.com with SMTP id o126so86539503iod.0 for ; Thu, 07 Apr 2016 13:55:03 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.30.71 with SMTP id e68mr5638869ioe.145.1460062503318; Thu, 07 Apr 2016 13:55:03 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Thu, 7 Apr 2016 13:55:03 -0700 (PDT) In-Reply-To: References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <57067AFE.9070704@alum.mit.edu> <5706B499.9030209@alum.mit.edu> Date: Thu, 7 Apr 2016 16:55:03 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1140d71edc677f052feb4a6a Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:55:07 -0000 --001a1140d71edc677f052feb4a6a Content-Type: text/plain; charset=UTF-8 On Thu, Apr 7, 2016 at 4:09 PM, Martin Thomson wrote: > On 7 April 2016 at 16:54, Roman Shpount wrote: > > Let me try to explain this again why this will not work. Consider that > RTP > > and RTCP can come from two different sources (devices) which will use > > different DTLS associations for each component, use different > certificates, > > and potentially support different sets of hash functions. Because of > this, > > the fact that RTP device supports SHA-256 does not mean that RTCP will > use > > it or support it. > > How is that relevant? If the RTCP endpoint doesn't support X, then it > uses what it can. > Let me clarify, let's say RTP device supports SHA-256 and SHA-1 and RTCP device supports SHA-1 only. The combined offer from these two devices will have an m= line with 3 fingerprints: SHA-256 and SHA-1 fingerprint for RTP device certificate and SHA-1 fingerprint for RTCP device certificate. When the other end point gets DTLS association from RTP device, two fingerprints will match (one SHA-1 and one SHA-256). When remote end point gets DTLS association from RTCP device only one SHA-1 fingerprint will match. If I understand your proposal correctly this will cause DTLS association for RTCP to be rejected since it did not match a single SHA-256 fingerprint. This is definitely undesirable. Regards, _____________ Roman Shpount --001a1140d71edc677f052feb4a6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 7, 2016 at 4:09 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
=
On 7 April 2016 at 16:54, Roman Shpount &= lt;roman@telurix.com> wrote: > Let me try to explain this again why this will not work. Consider that= RTP
> and RTCP can come from two different sources (devices) which will use<= br> > different DTLS associations for each component, use different certific= ates,
> and potentially support different sets of hash functions. Because of t= his,
> the fact that RTP device supports SHA-256 does not mean that RTCP will= use
> it or support it.

How is that relevant?=C2=A0 If the RTCP endpoint doesn't support= X, then it
uses what it can.

Let me clarify, let= 's say RTP device supports SHA-256 and SHA-1 and RTCP device supports S= HA-1 only. The combined offer from these two devices will have an m=3D line= with 3 fingerprints: SHA-256 and SHA-1 fingerprint for RTP device certific= ate and SHA-1 fingerprint for RTCP device certificate. When the other end p= oint gets DTLS association from RTP device, two fingerprints will match (on= e SHA-1 and one SHA-256). When remote end point gets DTLS association from = RTCP device only one SHA-1 fingerprint will match. If I understand your pro= posal correctly this will cause DTLS association for RTCP to be rejected si= nce it did not match a single SHA-256 fingerprint. This is definitely undes= irable.

Regards,
_____________
Roman Shpount

--001a1140d71edc677f052feb4a6a-- From nobody Thu Apr 7 14:13:39 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C49012D6E9 for ; Thu, 7 Apr 2016 14:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 GHrTmkpL9Gup for ; Thu, 7 Apr 2016 14:13:35 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C4912D10C for ; Thu, 7 Apr 2016 14:13:35 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id g185so109434976ioa.2 for ; Thu, 07 Apr 2016 14:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=QsJgDRdL30EsoGYEVtwaMt9q9PFYbVy47fKeowiv3aA=; b=HGaUB5/mVvVYuYmrGy3lMJcou5gaWsxtrtPnP/p0sovkhq4kN3gilKSfPFC+DE+3JE 621VbCmp8MkqPtLjDlQrW2Schmjk1UMXD7yK8xbT3VC9tPdcby1TGGtSnVzKszLRvpYF 5GLsqL6IxgIVc0n/d6xXqyZBkzf2saVvC7x7UNFsc5QDSTYLDpYt3z0usgKdM+AX7TH1 2WnXxU7pf2BS+uXfcRqEOnWcvn1SdCWV7WjAwivlqeouFuLnxPsaP4jjBD46JhdI5ACQ r8Z4BRpK60qkmx5BfeXfAKX+dKwTe8psmomyh/9GrKUMDCQ4t5uZAnpdkOdvSWkO0kqV cT6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=QsJgDRdL30EsoGYEVtwaMt9q9PFYbVy47fKeowiv3aA=; b=PLA74zumae7G3D02k9GOF1nPD4OQOgz5o5ACW9wgxg7wz1U+9yQB2qNwTigViMJolV X2RYf+ZZkAXhqNWRfpBfdDdw4OcoNXBxBJWi0+ZMj0UNLFicafMR0KGXXgr3e3Vb6q0N N4fkRQO2czbfkNCN2jwunkxI9NSiMzy58rlEOr1zCNbxxGgQ3yO6ODPguypWJNTDLN/s 8qB3M1ToXVw/NIS7d2hUz1OeS1JQJOqL+fHt+HyY46ilHpYlmhq2KK9OIYWwnd525cvl fhq92Tk5eH0NVfcWwI4V6PY2MYcxYz42OSc34lOUX8NDEIB350BRBs6flIP/2PVI6cc9 MYOg== X-Gm-Message-State: AD7BkJIbZwewd+h7GYub+Kzp3WnmmcO6yDoqtvy/9dqS2ue5r7jiERihlgY2M3aSn63m9uR48H/WlR827lDBQA== MIME-Version: 1.0 X-Received: by 10.107.166.72 with SMTP id p69mr5757762ioe.100.1460063614477; Thu, 07 Apr 2016 14:13:34 -0700 (PDT) Received: by 10.36.43.5 with HTTP; Thu, 7 Apr 2016 14:13:34 -0700 (PDT) In-Reply-To: References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <57067AFE.9070704@alum.mit.edu> <5706B499.9030209@alum.mit.edu> Date: Thu, 7 Apr 2016 18:13:34 -0300 Message-ID: From: Martin Thomson To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:13:37 -0000 On 7 April 2016 at 17:55, Roman Shpount wrote: > If I understand your proposal correctly this will cause DTLS association for > RTCP to be rejected since it did not match a single SHA-256 fingerprint. > This is definitely undesirable. Well, the entity generating the SDP is not constrained by the hashes that the two devices support, is it? But, assuming that it is, then my original text did have the property you describe. From nobody Thu Apr 7 14:25:56 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C534712D6FB for ; Thu, 7 Apr 2016 14:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 bIPHAuRAVYQA for ; Thu, 7 Apr 2016 14:25:53 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6442812D6D7 for ; Thu, 7 Apr 2016 14:25:53 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id q128so109682219iof.3 for ; Thu, 07 Apr 2016 14:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=QUgc18xgkM+Yulx0/nsQxMJSWIiMxQCj1/BBSfmTcGA=; b=BnlRmzpEK00SzyxyOMwjmSgRoVq0+BoX3VVNPWIfHKQo+GhTERA6Ta8Dn5giuo2oxV +egxoSRK/uQFToVYafUTsXrNE1wPyJKumSyenVUVp1B+z3lYANatvoiPhBEvC5DP74/7 BV2oVhwOYNJ+e8sA0b09iu4oOauoDCbLDyYw3eYUpevcrd4eY5Rkxn5a266qRZswvlRA qdcatGCh2ZmxrgrMUWyqW0WzDNepQMar8pvCKwJkMowZ17GRXIMg3yvpLu8YmsKjubwH Qdvb/7tZLgIz7KmIsTCXZBaFmip+b8DcwdobIH/BR8UbozkqejvFPs78o0v9l/NBiVtc AG3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=QUgc18xgkM+Yulx0/nsQxMJSWIiMxQCj1/BBSfmTcGA=; b=YSMujsnWkSFR2HMhm4a6GKxT7eORw5mdR4S/gnyVtBCpXEyqThMeYUl0WSwNU3LeWr UV/U99DnOZR4YidFHkefVLuA9lvjhW25jXtc6irmVeg4AphRW+Ce42vOk8cNYwYjf3+8 Pss+M72RqDx5C+KsY5o7jNnwrYGEE98dfQQ7UUWm3GASqemAqcg+ASHWmx8zZE4ZnAlJ oQKsHN1SzmiCOxynYzukVEdphzqOvOXtHFFG6xCnswZdKxKNfWJG7GWQrFOUbkxOGa0T aEaXoIFbHFdA++t0xPEPhTQF6lnmtV6ndDvvrvE6zgI1zgY6hcwfeslQSl0O6cAjm6MN Y5bw== X-Gm-Message-State: AD7BkJJbeVmxNIo9rO6p1mJhZm8BloJeRJxPP52+ZclvkZe6lILqOzk99LfzPMROYKsVkg== X-Received: by 10.107.19.42 with SMTP id b42mr5501570ioj.75.1460064352709; Thu, 07 Apr 2016 14:25:52 -0700 (PDT) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com. [209.85.223.169]) by smtp.gmail.com with ESMTPSA id zy9sm12603611igc.13.2016.04.07.14.25.51 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 14:25:52 -0700 (PDT) Received: by mail-io0-f169.google.com with SMTP id o126so87420951iod.0 for ; Thu, 07 Apr 2016 14:25:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr5239087ioe.38.1460064351587; Thu, 07 Apr 2016 14:25:51 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Thu, 7 Apr 2016 14:25:51 -0700 (PDT) In-Reply-To: References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <57067AFE.9070704@alum.mit.edu> <5706B499.9030209@alum.mit.edu> Date: Thu, 7 Apr 2016 17:25:51 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1140b47206baec052febb9ea Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:25:54 -0000 --001a1140b47206baec052febb9ea Content-Type: text/plain; charset=UTF-8 On Thu, Apr 7, 2016 at 5:13 PM, Martin Thomson wrote: > On 7 April 2016 at 17:55, Roman Shpount wrote: > > If I understand your proposal correctly this will cause DTLS association > for > > RTCP to be rejected since it did not match a single SHA-256 fingerprint. > > This is definitely undesirable. > > Well, the entity generating the SDP is not constrained by the hashes > that the two devices support, is it? > This all depends on the architecture. In the solution I had to deal with RTP and RTCP would generate temporary certificates and send only fingerprints to the device which produced final SDP. I do agree this is esoteric. But, assuming that it is, then my original text did have the property > you describe. > _____________ Roman Shpount --001a1140b47206baec052febb9ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 7, 2016 at 5:13 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
=
On 7 April 2016 at 17:55, Roman Shpount &= lt;roman@telurix.com> wrote: > If I understand your proposal correctly this will cause DTLS associati= on for
> RTCP to be rejected since it did not match a single SHA-256 fingerprin= t.
> This is definitely undesirable.

Well, the entity generating the SDP is not constrained by the hashes=
that the two devices support, is it?

Th= is all depends on the architecture.=C2=A0 In the solution I had to deal wit= h RTP and RTCP would generate temporary certificates and send only fingerpr= ints to the device which produced final SDP.

I do = agree this is esoteric.

But, assuming = that it is, then my original text did have the property
you describe.

_____________
Roman Shpount

<= /div>
--001a1140b47206baec052febb9ea-- From nobody Thu Apr 7 14:31:06 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44EB12D10C for ; Thu, 7 Apr 2016 14:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 Nmn3Y4WYDamP for ; Thu, 7 Apr 2016 14:31:02 -0700 (PDT) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C822812D5E7 for ; Thu, 7 Apr 2016 14:31:01 -0700 (PDT) Received: by mail-io0-x242.google.com with SMTP id g185so14038267ioa.0 for ; Thu, 07 Apr 2016 14:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=t7zDJtdcTO3IxFF8faoV4/wfs32n3Np3dWTjMUvmf5o=; b=IITm2ekghpc6qsONWo//sS32nZTWLig7u6FZFFOjJ39J7Waxvmido2xKXsMQ/nbsRB EANh6hnWcypIOh80Uhu1VIeAWj4M8fpMwavb9amMT1Z2QCTZBUsIjR5H/mDs5Qrw2NKP D8tUdnb86qjxfUERvZ4kj5q3XwP62RlN5i7dZq38LqqzH9KE1Z5jhDDqV6hwD8kIdQxm iUBGP+4dj0Po0KF1+ZjyP12cjI7w6VLcv24HnuQqTLycQvWttOxBvb8VtPrEBnwE6UQH hhyTmFwKEZUL3VR/+d/8/bctLtyf2lbKPndX4ZK7y8/qKYcmqta0NdBgsSBWagUwWf4+ omSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=t7zDJtdcTO3IxFF8faoV4/wfs32n3Np3dWTjMUvmf5o=; b=kKOn9oWW4B0AQ66vxrPYaYF0/j2+U8RRXA4/eYlIbIq/tWg2gGYJZI+YYOTPlGV8fv rG8VbBZKz8KqFYQJt9gtfwAuw4Xcmsm2iuDv9I4pOu1TYcfsM/fEDd3svytVa9FXdtLI 7ZQ5Nwpa6SY2Iz/Y9rp18He5R3veKUZ9p5LvLfWYgQTfDAr+HLAE0YhBhnw1QT2h+PrN SKqDi0tZTKBQilLAR99bo2i1y+rMMg8X/cKUmmDJMCJAtOqDaorcfsuG32vBSvCpOItx EX33S7r/okr2NPHEx2EJkpboDPysRUl9io/d57gvOgJi8igl7y/XHGLAysmNf5VqRcQJ KpoQ== X-Gm-Message-State: AD7BkJJvOJceQaZFNhEtUdJFd6/+8zDpHHgbB0QtseiPmJPHY29QTXkLkQHn3y/jOByQtQ== X-Received: by 10.107.134.166 with SMTP id q38mr5439135ioi.165.1460064661228; Thu, 07 Apr 2016 14:31:01 -0700 (PDT) Received: from mail-io0-f170.google.com (mail-io0-f170.google.com. [209.85.223.170]) by smtp.gmail.com with ESMTPSA id s40sm4631144ioi.9.2016.04.07.14.31.00 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 14:31:00 -0700 (PDT) Received: by mail-io0-f170.google.com with SMTP id g185so109905813ioa.2 for ; Thu, 07 Apr 2016 14:31:00 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr5253168ioe.38.1460064660307; Thu, 07 Apr 2016 14:31:00 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Thu, 7 Apr 2016 14:31:00 -0700 (PDT) In-Reply-To: <5706751F.7030009@ericsson.com> References: <5706751F.7030009@ericsson.com> Date: Thu, 7 Apr 2016 17:31:00 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Magnus Westerlund Content-Type: multipart/alternative; boundary=001a1140b4726d69f9052febcb48 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] a=rtcp-mux-exclusive vs a=rtcp:0 compression X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:31:04 -0000 --001a1140b4726d69f9052febcb48 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 7, 2016 at 10:56 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Den 2016-04-05 kl. 18:36, skrev Roman Shpount: > >> I have modified the proposed SDP slightly. I have removed IN IP4 0.0.0.0 >> from a=rtcp attribute. I cannot find a place that states that a=rtcp is >> required when rtcp-mux is used, so I removed a=rtcp from the >> rtcp-mux-exclusive examples. >> > > So, I would agree that a=rtcp is not mandatory based on RFC 5761, it do > results in that the fall back for RTCP is m= port+1. But, as this is > intended for the case of not having any fallback. > I assumed since we are doing a new attribute that specifies that there is no fallback, then a=rtcp attribute can be omitted. However JSEP do contain text that appears to require that a=rtcp are > included. This, may be changed to support the mux-exclusive usage. However, > I haven't checked if this requirement is due to trickle ICE. > JSEP includes requirement for a=rtcp due to https://tools.ietf.org/html/rfc5245#section-4.3 : If the agent is utilizing RTCP, it MUST encode the RTCP candidate using the a=rtcp attribute as defined in RFC 3605 [RFC3605]. This was already fixed in https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-08#section-4.2 : If the agent is utilizing RTCP and if RTCP candidate is present and is not equal to the same address and the next higher port number of the RTP candidate, the agent MUST encode the RTCP candidate using the a=rtcp attribute as defined in RFC 3605 [RFC3605]. _____________ Roman Shpount --001a1140b4726d69f9052febcb48 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 7, 2016 a= t 10:56 AM, Magnus Westerlund <magnus.westerlund@ericsson.com= > wrote:
Den 2016-04-05 kl. 18:36, skrev Roman Shpount:
I have modified the proposed SDP slightly. I have removed IN IP4 0.0.0.0 from a=3Drtcp attribute. I cannot find a place that states that a=3Drtcp is=
required when rtcp-mux is used, so I removed a=3Drtcp from the
rtcp-mux-exclusive examples.

So, I would agree that a=3Drtcp is not mandatory based on RFC 5761, it do r= esults in that the fall back for RTCP is m=3D port+1. But, as this is inten= ded for the case of not having any fallback.

=C2=A0I assumed since we are doing a new attribute that specifies tha= t there is no fallback, then a=3Drtcp attribute can be omitted.=C2=A0
=

However JSEP do contain text that appears t= o require that a=3Drtcp are included. This, may be changed to support the m= ux-exclusive usage. However, I haven't checked if this requirement is d= ue to trickle ICE.

JSEP includes requir= ement for a=3Drtcp due to=C2=A0https://tools.ietf.org/html/rfc5245#section-4.3=C2=A0:<= /div>

= If the agent is utilizing RTCP, it MUST encode the RTCP candidate using the= a=3Drtcp attribute as defined in RFC 3605 =C2=A0[RFC3605].

Th= is was already fixed in https://tools.ietf.org/html/draft-ietf-mm= usic-ice-sip-sdp-08#section-4.2 :

<= /div>
If the agent is utilizing RTCP and if=C2=A0RTCP candid= ate is present and is not equal to the same address and=C2=A0the next highe= r port number of the RTP candidate, the agent MUST=C2=A0encode the RTCP can= didate using the a=3Drtcp attribute as defined in=C2=A0RFC 3605 [RFC3605].<= /div>
_____________
Roman Shpount
=C2=A0
--001a1140b4726d69f9052febcb48-- From nobody Thu Apr 7 14:38:04 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C1C12D640 for ; Thu, 7 Apr 2016 14:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Y79dCZcOvVd1 for ; Thu, 7 Apr 2016 14:38:01 -0700 (PDT) Received: from smtp98.iad3a.emailsrvr.com (smtp98.iad3a.emailsrvr.com [173.203.187.98]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC3F12D72A for ; Thu, 7 Apr 2016 14:37:59 -0700 (PDT) Received: from smtp21.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp21.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C37EF1803BA; Thu, 7 Apr 2016 17:37:58 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp21.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 9080F1805D4; Thu, 7 Apr 2016 17:37:55 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.67.47] ([UNAVAILABLE]. [128.107.241.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Thu, 07 Apr 2016 17:37:58 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_173AA3F5-384F-468F-AF1C-7089E0843424" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Thu, 7 Apr 2016 18:37:50 -0300 Message-Id: <4F76BA3A-A69A-473E-97DA-287E6E571324@iii.ca> References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F27D6E@ESESSMB209.ericsson.se> To: Roman Shpount X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jonathan Lennox , mmusic , Christer Holmberg Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:38:03 -0000 --Apple-Mail=_173AA3F5-384F-468F-AF1C-7089E0843424 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 7, 2016, at 11:20 AM, Roman Shpount wrote: >=20 > You should check all the hashes you consider secure and if any one of = them matches the DTLS association certificate, accept the media. +1=20 This allows us to do things like include hash for two servers even when = you re not sure which server will actually be used.=20 --Apple-Mail=_173AA3F5-384F-468F-AF1C-7089E0843424 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Apr 7, 2016, at 11:20 AM, Roman Shpount <roman@telurix.com> = wrote:

You should check all the hashes you consider = secure and if any one of them matches the DTLS association certificate, = accept the media.

+1 

This allows us to do things like include hash for two servers = even when you re not sure which server will actually be = used. 


= --Apple-Mail=_173AA3F5-384F-468F-AF1C-7089E0843424-- From nobody Fri Apr 8 07:40:02 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86B212D0CF for ; Fri, 8 Apr 2016 07:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Wt2-Q02z763L for ; Fri, 8 Apr 2016 07:39:59 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C807127058 for ; Fri, 8 Apr 2016 07:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1478; q=dns/txt; s=iport; t=1460126399; x=1461335999; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=vdCysDLkKuA9x8wJcrUFYitg+f2UwnUMUn6kXVN9RXo=; b=i/9Vcg/ZWFkamT6+P9tmEdVGQtDlDF3GKxnnikLm5k0WP3JS9Gny6h0P CJR/y/weDyAXdZEJPTLpbgx2YAt+PAByGh9xW1xDbmSYzPYP/gCC9xt/E 5ySqyzc6+BrrjAzl9yEOH92e85bXu5MmKQemIIXNtpIBDYAP91Z8vX69q Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAgB8wgdX/5FdJa1cgzdTfbIZgRyEC?= =?us-ascii?q?SeCYAENgXMhhyE4FAEBAQEBAQFlJ4RrFTYKNgIFFgsCCwMCAQIBSw0IAQEXiAw?= =?us-ascii?q?Onm+PXZICAQEBAQEFAQEBARgEfIUljAqCVgEEmASBLYZ4gkODJIFnhE2DBYVUj?= =?us-ascii?q?yUeAQFChAMgMAGJOAEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,454,1454976000"; d="scan'208";a="95204256" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2016 14:39:36 +0000 Received: from [10.82.232.203] (rtp-vpn5-203.cisco.com [10.82.232.203]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u38EdZxL029651 for ; Fri, 8 Apr 2016 14:39:35 GMT To: mmusic From: Flemming Andreasen Message-ID: <5707C2A6.2060001@cisco.com> Date: Fri, 8 Apr 2016 10:39:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [MMUSIC] The way forward wih mux-exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 14:40:01 -0000 Greetings We recently went through WGLC on the mux-exclusive draft (https://www.ietf.org/id/draft-ietf-mmusic-mux-exclusive-03.txt). Following the WGLC, a question was raised as to whether we really need the mux-exclusive mechanism described in the draft or not. The issue was discussed further in the MMUSIC WG meeting this week in Buenos Aires which yielded the following outcomes: - There was agreement that we should have a signaled solution - It's important to get a solution quickly since this issue is holding up progress on other drafts that rtcweb is dependent on - The only two proposals that got support were "rtcp:0" and "rtcp-mux-exclusive" - Everybody in the room could live with either "rtcp:0" or "rtcp-mux-exclusive" - A hum between the two slightly favored "rtcp-mux-exclusive, but overall it was inconclusive in forming a consensus A couple of key participants in the mailing list discussion (EKR and Martin Thomson) were not able to attend to attend the MMUSIC session, however Christer subsequently met with them, and they they graciously agreed to respect the consensus established in the meeting. Based on all of this, and since we currently have a WG adopted draft for rtcp-mux-exclusive that went through a WGLC already, we want to continue with the rtcp-mux-exclusive solution. If anybody objects to this, please let us know no later than Friday, April 15. Thanks Bo & Flemming (MMUSIC chairs) From nobody Fri Apr 8 08:09:01 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBE712D93B for ; Fri, 8 Apr 2016 08:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 cU6uR9Uaz8uF for ; Fri, 8 Apr 2016 08:08:59 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AAC012D943 for ; Fri, 8 Apr 2016 08:08:57 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by comcast with SMTP id oY1FaJ7Crp1BeoY1mamsi9; Fri, 08 Apr 2016 15:08:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460128134; bh=Ldm5eANuiX4GFIRlQgAu3YZe1KB1dhvF0o9xFoie46c=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=MnJhbFkFunzGJG/6vi/R2/1ej5gfH/2aN+7kKVoO3bgTELHc0m87ifwhmlZUHTx3r /F8+1sq5gJh4kUxelV9mPa/0xAr8pH/i8UMsSe8JQAmPkjRyc1n1SUm504CL9GxJQN YurD5J9V/b1Ks/QhdXQoBN6jd6MF1UYHrosoI1DPWNrvSLzjiZRaEuwwaMc8Y/HXl0 VkQUWIjL70YraHeoBzJLVrE+PYdFcgHXyCUJxfptA4UPaO+BrzCtRRxxvX98SaaCAv P4j8F6+MlEGEBXHk18aaS0fJ3YnrL4563X+qI+v2sSm/AzE2k0gWbZk1L5X4FHdk+h 4yFULQjE7Scqg== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-16v.sys.comcast.net with comcast id fr8t1s00K3KdFy101r8tbM; Fri, 08 Apr 2016 15:08:54 +0000 To: mmusic@ietf.org References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F27D6E@ESESSMB209.ericsson.se> <4F76BA3A-A69A-473E-97DA-287E6E571324@iii.ca> From: Paul Kyzivat Message-ID: <5707C985.5060809@alum.mit.edu> Date: Fri, 8 Apr 2016 11:08:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <4F76BA3A-A69A-473E-97DA-287E6E571324@iii.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 15:09:00 -0000 I don't have a horse in this race. I think those of you who do need to finish deciding what the rules are for multiple fingerprints, and then write the result into the draft update. Clearly it is ambiguous at the moment. Thanks, Paul On 4/7/16 5:37 PM, Cullen Jennings wrote: > >> On Apr 7, 2016, at 11:20 AM, Roman Shpount > > wrote: >> >> You should check all the hashes you consider secure and if any one of >> them matches the DTLS association certificate, accept the media. > > +1 > > This allows us to do things like include hash for two servers even when > you re not sure which server will actually be used. > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Fri Apr 8 12:14:33 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B3612D1BC for ; Fri, 8 Apr 2016 12:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 HcDnCJ2o745b for ; Fri, 8 Apr 2016 12:14:30 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5B5D12D0B0 for ; Fri, 8 Apr 2016 12:14:29 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id g185so143137052ioa.2 for ; Fri, 08 Apr 2016 12:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=LxTdumfX5b1oC6F5sPjln7vdMqVPMivPxO4IFh6x3UQ=; b=ltxYnjiEdy4EteNpC9AnyU8l2JISAzNPM9/nPY2reJl5DHxtrT5VZb5W1uGhonSJEH VK7fa6C1lUMGPJ2n95Xmg6Hqc5BTLW1clQnQbk3Y3CLq7u3K3YYsD0aIDKaBLO8mmr7l cdGtcrbxKZal5BbzorbmM7t0WaXOjsxJ3V3J2maGT5v3TwS9lE8csYL7oiOJri56std8 ZYDGUgv/jL6IKn0Q3GFJ8oGuMdv6g/RtWFBF4qE7gVCohe9HMKLef6GxCgrKxJ0uTkTy fDmTAa6ZBKogM45iZlPfq1+BacqILD87gX8HdE4nguTydV88HRN9imvQW83A2eXxT7jM NcQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=LxTdumfX5b1oC6F5sPjln7vdMqVPMivPxO4IFh6x3UQ=; b=aw+lBukFb06NTyHkCla8/hX1dDfCzuCi70NiMCcud7b7IBB5MAkbjlkNGx8EtNiSVM Fqhmiy84M0x/nBsoZNs7RoZaH6z6lIWXqSVNMBLYwW3+0f49hXcbhBtjWbSNTpKg1mXM HZKsbIOTmmiGewbe1g0nYUoWepPs4EeCcPU39mQzc2LRO6EpUQ8caiiCBspzKUHEeDOo 5a1AItKDdYhXk/bOjdfQi60C+cBWiHaPm+IBvw8mVQq+CnWmcZrhHb0ls/RcSrrl5Rlu lXoWOTIG5LMAkMMLlG68Si0881HuoV/tZgjgu+jnbNvhunkP8q9nRuYQs8YNi+5XFTWY 77GA== X-Gm-Message-State: AOPr4FXhHLJTWH0abhUX76A3eCI7tjpzt7F9NkmPm/I0oL5Dz4FwtCJ+h52Q+ZbjeBEDSw== X-Received: by 10.107.59.80 with SMTP id i77mr497651ioa.36.1460142869058; Fri, 08 Apr 2016 12:14:29 -0700 (PDT) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com. [209.85.223.178]) by smtp.gmail.com with ESMTPSA id cl9sm2822586igc.10.2016.04.08.12.14.28 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2016 12:14:28 -0700 (PDT) Received: by mail-io0-f178.google.com with SMTP id 2so143134290ioy.1 for ; Fri, 08 Apr 2016 12:14:28 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.30.71 with SMTP id e68mr11442591ioe.145.1460142867950; Fri, 08 Apr 2016 12:14:27 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Fri, 8 Apr 2016 12:14:27 -0700 (PDT) In-Reply-To: <5707C985.5060809@alum.mit.edu> References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F27D6E@ESESSMB209.ericsson.se> <4F76BA3A-A69A-473E-97DA-287E6E571324@iii.ca> <5707C985.5060809@alum.mit.edu> Date: Fri, 8 Apr 2016 15:14:27 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a1140d71ef743cc052ffe0065 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 19:14:32 -0000 --001a1140d71ef743cc052ffe0065 Content-Type: text/plain; charset=UTF-8 I just wanted to re-iterate the question. We have two options: 1. If m= line has multiple fingerprints with hash functions X, Y, Z, at least one fingerprint with each function must match DTLS association for the media to be accepted. For example, if m= line has two fingerprints with hash function SHA-1, and two with SHA-512, DTLS association certificate must match at least one SHA-1 and one SHA-512 fingerprint. 2. If m= line has multiple fingerprints with hash functions X, Y, Z, at least one fingerprint with any hash function which is considered secure enough must match DTLS association for the media to be accepted. For example, if m= line has two fingerprints with hash function SHA-1, and two with SHA-512, DTLS association certificate must match one of either SHA-1 or SHA-512 fingerprints. Option 1 has a benefit of being more secure since it provides the combined secure of individual hash functions. It does put additional restrictions how equipment can be combined into producing a single m= line. For instance if fingerprints from two servers are combined into a single m= line and it is not known in advance which one will be used, both servers will need to always support the same hash functions and be updated at the same time. Option 2 is less secure since it is only as secure as the least secure hash. On the other hand option 2 allows to be more flexible in how equipment is combined to form the single m= line. Two servers in above example, for instance, can support different hash functions. I would ask the group to state their preferences. I prefer option 2 but can live with option 1. Regards, _____________ Roman Shpount On Fri, Apr 8, 2016 at 11:08 AM, Paul Kyzivat wrote: > I don't have a horse in this race. I think those of you who do need to > finish deciding what the rules are for multiple fingerprints, and then > write the result into the draft update. Clearly it is ambiguous at the > moment. > > Thanks, > Paul > > On 4/7/16 5:37 PM, Cullen Jennings wrote: > >> >> On Apr 7, 2016, at 11:20 AM, Roman Shpount >> > wrote: >>> >>> You should check all the hashes you consider secure and if any one of >>> them matches the DTLS association certificate, accept the media. >>> >> >> +1 >> >> This allows us to do things like include hash for two servers even when >> you re not sure which server will actually be used. >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a1140d71ef743cc052ffe0065 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I just wanted to re-iterate the question. We have two opti= ons:

1. If m=3D line has multiple fingerprints with hash= functions X, Y, Z, at least one fingerprint with each function must match = DTLS association for the media to be accepted. For example, if m=3D line ha= s two fingerprints with hash function SHA-1, and two with SHA-512, DTLS ass= ociation certificate must match at least one SHA-1 and one SHA-512 fingerpr= int.

2. If m=3D line has multiple fingerprints wit= h hash functions X, Y, Z, at least one fingerprint with any hash function w= hich is considered secure enough must match DTLS association for the media = to be accepted. For example, if m=3D line has two fingerprints with hash fu= nction SHA-1, and two with SHA-512, DTLS association certificate must match= one of either SHA-1 or SHA-512 fingerprints.

Opti= on 1 has a benefit of being more secure since it provides the combined secu= re of individual hash functions. It does put additional restrictions how eq= uipment can be combined into producing a single m=3D line. For instance if = fingerprints from two servers are combined into a single m=3D line and it i= s not known in advance which one will be used, both servers will need to al= ways support the same hash functions and be updated at the same time.
=

Option 2 is less secure since it is only as secure as t= he least secure hash. On the other hand option 2 allows to be more flexible= in how equipment is combined to form the single m=3D line. Two servers in = above example, for instance, can support different hash functions.

I would ask the group to state their preferences.

I prefer option 2 but can live with option 1.=C2=A0
<= div>
Regards,

_____________
Roman Shpount=

On Fri, Apr 8, 2016 at 11:08 AM, Paul Kyziva= t <pkyzivat@alum.mit.edu> wrote:
I don't have a horse in this race. I think those of you who = do need to finish deciding what the rules are for multiple fingerprints, an= d then write the result into the draft update. Clearly it is ambiguous at t= he moment.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

On 4/7/16 5:37 PM, Cullen Jennings wrote:

On Apr 7, 2016, at 11:20 AM, Roman Shpount <roman@telurix.com
 <mailto:roman@tel= urix.com>> wrote:

You should check all the hashes you consider secure and if any one of
them matches the DTLS association certificate, accept the media.

+1

This allows us to do things like include hash for two servers even when
you re not sure which server will actually be used.




 _______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic


_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic

--001a1140d71ef743cc052ffe0065-- From nobody Fri Apr 8 13:06:07 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5CD12D631 for ; Fri, 8 Apr 2016 13:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 zAiiUyUAlvYQ for ; Fri, 8 Apr 2016 13:06:04 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFDB612D625 for ; Fri, 8 Apr 2016 13:06:04 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by comcast with SMTP id ocfIafunAVEtuocfMaracV; Fri, 08 Apr 2016 20:06:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460145964; bh=uuBWXno4ocEakHM3XJHdSH7hddwl9ekJ/b4aNQy1iRs=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=k4y2uWfBOBEAjt+EmlW4MloaW7QRx4eYhzLhUU5BM5SBKofymOtOkCTGaG0uta29R h2SWxPut6FiCYGeMkZqb4RucuJLLKQGNMuBLWutQjWgiR52r7DsvGYu09BEroPGzze kvQXFA1GVPTScHXlRG1Kh6dFTjElsUfYfFMnDSfL2bR7y7StFNkBdX+XMB8mCRmuCw ZCCYfWK6unn9i5W6szXb+ihL5xUl73o7aJgywSQ3/u2kIWzgUmUchqFtfZHBs1gTQA Ccqi+BOYMl4fB2WZpXUXxxir1ggadTrjQdKk26ifJl2z+Rpc0SRzxQgfEg8pgGWxdD JoM/0EDpyoJDg== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-12v.sys.comcast.net with comcast id fw631s00B3KdFy101w63eK; Fri, 08 Apr 2016 20:06:04 +0000 To: Roman Shpount References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F27D6E@ESESSMB209.ericsson.se> <4F76BA3A-A69A-473E-97DA-287E6E571324@iii.ca> <5707C985.5060809@alum.mit.edu> From: Paul Kyzivat Message-ID: <57080F29.5060402@alum.mit.edu> Date: Fri, 8 Apr 2016 16:06:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 20:06:05 -0000 On 4/8/16 3:14 PM, Roman Shpount wrote: > I just wanted to re-iterate the question. We have two options: > > 1. If m= line has multiple fingerprints with hash functions X, Y, Z, at > least one fingerprint with each function must match DTLS association for > the media to be accepted. For example, if m= line has two fingerprints > with hash function SHA-1, and two with SHA-512, DTLS association > certificate must match at least one SHA-1 and one SHA-512 fingerprint. > > 2. If m= line has multiple fingerprints with hash functions X, Y, Z, at > least one fingerprint with any hash function which is considered secure > enough must match DTLS association for the media to be accepted. For > example, if m= line has two fingerprints with hash function SHA-1, and > two with SHA-512, DTLS association certificate must match one of either > SHA-1 or SHA-512 fingerprints. > > Option 1 has a benefit of being more secure since it provides the > combined secure of individual hash functions. It does put additional > restrictions how equipment can be combined into producing a single m= > line. For instance if fingerprints from two servers are combined into a > single m= line and it is not known in advance which one will be used, > both servers will need to always support the same hash functions and be > updated at the same time. > > Option 2 is less secure since it is only as secure as the least secure > hash. On the other hand option 2 allows to be more flexible in how > equipment is combined to form the single m= line. Two servers in above > example, for instance, can support different hash functions. > > I would ask the group to state their preferences. > > I prefer option 2 but can live with option 1. I don't have a preference. But I will observe that a problem here arises because fingerprints for multiple DTLS associations don't identify which association they are intended for. Obviously the source of the fingerprints has this information. Discarding that info is complicating the algorithm. Thanks, Paul From nobody Fri Apr 8 15:01:33 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8632A12D954 for ; Fri, 8 Apr 2016 15:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 Cn79D9PVxAPD for ; Fri, 8 Apr 2016 15:01:30 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6368412D94E for ; Fri, 8 Apr 2016 15:01:30 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by comcast with SMTP id oeP0aJke3p1BeoeT3aoUlh; Fri, 08 Apr 2016 22:01:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460152889; bh=YQ97lFLCbU9ecMNagjV2WwAsxiLJYAFNwCEoWhMUV8M=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=ATYIk7c0xBDfnRbcGrxWOVU1sdRYVz2BDvI5xYWlfx4NT28SKm17ujMLvYZa3aSR4 xftparKsYG9BsFGSEAJiAXBHUcziGsWY10Y6NNw/XI9o1jIj5ng2WWKkULTZ+qbIKd 8MuO2mAbEpLQyBzfKZuLNTTzazx4/aTMHL/UsqtcyhaUOIlBkp2AKKqQxvKt19s4dl eDnUaWwdJeWT9e/JY+ViHzAIbK9wUh7fI+HGTGR7Y3HObipUvjF7cf/U0AzXyd6mlU z8lRxxM0du3sUn8qBeeng2yu0kwrfWd2UdatggPIAytrtotfFyNkGlldD1z0Vb0mTI zTNOHYXNmCYIA== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-17v.sys.comcast.net with comcast id fy1V1s0083KdFy101y1Vso; Fri, 08 Apr 2016 22:01:29 +0000 To: mmusic@ietf.org References: <5707C2A6.2060001@cisco.com> From: Paul Kyzivat Message-ID: <57082A38.9050407@alum.mit.edu> Date: Fri, 8 Apr 2016 18:01:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <5707C2A6.2060001@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] The way forward wih mux-exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 22:01:32 -0000 On 4/8/16 10:39 AM, Flemming Andreasen wrote: > Based on all of this, and since we currently have a WG adopted draft for > rtcp-mux-exclusive that went through a WGLC already, we want to continue > with the rtcp-mux-exclusive solution. If anybody objects to this, please > let us know no later than Friday, April 15. I support this direction. During the meeting I expressed a preference for a=rtcp:0. My reason for this is simply that it exists, and thus is better, other things being equal, than something new. However, on further reflection, I'm changing my mind, and preferring rtcp-mux-exclusive. The reason is because the O/A behavior for a=rtcp doesn't give us an ack for use of rtcp-mux. (RFC3605 says nothing about O/A. And given the definition of this attribute, putting it in the answer implicitly says where rtcp should be sent to the answerer.) With rtcp-mux-exclusive we are free to define the O/A behavior. The draft already does so, with presence in the answer serving as an ack. So this way the offerer will be able to detect if the answerer doesn't support this and can then take appropriate remedial action. There may still be some RTCP sent to an unassigned port, but the offerer can prevent it from continuing. Thanks, Paul From nobody Fri Apr 8 15:15:34 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5263D12D5A5 for ; Fri, 8 Apr 2016 15:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 GJLN4FbhjMis for ; Fri, 8 Apr 2016 15:15:31 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 387D412D5BD for ; Fri, 8 Apr 2016 15:15:31 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id q128so147765251iof.3 for ; Fri, 08 Apr 2016 15:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=pKTtK2OCe+0CCDywIX8nSm+TFdE0XxwSQhcNO+qa5TI=; b=Id+L0onpthVCyjpFJ0osVIjeFMdevjtmCioeNrDgBNseLZUEkktl0lWq9p9kaIWIh1 SYBnrzeZyQR5l/B8DmhcSEUAL4cnaiJCySe30soIlhby5f4Za9dvieGASYZNm5RXHH8E b2sWg3FfcoMRDiQuGrjdUML6XQWiFqNvvCJ2ZgJXml4UM2ejj3RxOhhR7GFU3YhvIbOC l7GZX+ejEuDrIj6lUt6iV+ZN4lpfXpW0a2FK5tr4vOUaCNg3gtLEvaLUhw0p/VjJGZNU fOQqUrpVxufiKrMKHYIh1Ew1p1MdaN3B8swTI+kOEmN2w6vcII/Z/75prZh5nSp90roU p/WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=pKTtK2OCe+0CCDywIX8nSm+TFdE0XxwSQhcNO+qa5TI=; b=Hq0kfuY/J+/jwIRrCQSg6WsRvmFHwXyVUUPXTgeq4w29bqwhHm3TUE5BeOelMpz4gj p17Ib6UkVcddB2hUbZcmUd/5r4KI9g+1cdowtMlnbSIRF5fyCBfvaZiADSxa2NagQAMS j62U32HXmBDTMHveiWg2HUMxnMts0zsDUT9nykV8GapowW5AREXThKAVabd4S0wJPQDF W2G8oiXSWk5WzOkdcUvLsTzqeXaeMAM6B59dsKfoJXFQo36qQ1p6yCSDgbDGbLHKjCGk ZnqkPaTn8mW3GIkfaFeZJ7B+pJkPT5gA7dwJusBZeUXcDeVoqgyfXxz1f3xvRof6MMlZ tbOg== X-Gm-Message-State: AD7BkJJc8MpwGNXukikKgdEOdHV4Tic7R9vT/FmBzoRZlrdvpxlFYnn7vTzlRv6n2Xgy0w== X-Received: by 10.107.8.135 with SMTP id h7mr11175222ioi.85.1460153730429; Fri, 08 Apr 2016 15:15:30 -0700 (PDT) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com. [209.85.213.171]) by smtp.gmail.com with ESMTPSA id xg10sm3258628igb.13.2016.04.08.15.15.29 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2016 15:15:29 -0700 (PDT) Received: by mail-ig0-f171.google.com with SMTP id kb1so45654298igb.0 for ; Fri, 08 Apr 2016 15:15:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.66.171 with SMTP id g11mr6281907igt.96.1460153729454; Fri, 08 Apr 2016 15:15:29 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Fri, 8 Apr 2016 15:15:29 -0700 (PDT) In-Reply-To: <5707C2A6.2060001@cisco.com> References: <5707C2A6.2060001@cisco.com> Date: Fri, 8 Apr 2016 18:15:29 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Flemming Andreasen Content-Type: multipart/alternative; boundary=047d7bdc08a65cb7fe05300088d7 Archived-At: Cc: mmusic Subject: Re: [MMUSIC] The way forward wih mux-exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 22:15:33 -0000 --047d7bdc08a65cb7fe05300088d7 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 8, 2016 at 10:39 AM, Flemming Andreasen wrote: > Based on all of this, and since we currently have a WG adopted draft for > rtcp-mux-exclusive that went through a WGLC already, we want to continue > with the rtcp-mux-exclusive solution. If anybody objects to this, please > let us know no later than Friday, April 15. > I support this decision. I always had a preference for rtcp-mux-exclusive over anything a=rtcp: based since it avoids potential interop issues. I am not sure how existing implementations will react to a=rtcp:0. This is something that did no exist before and I am not sure if some implementations will not break in unexpected way because of a=rtcp:0. P.S. If some one really cares about the attribute size, we can always shave 5 bytes by renaming the attribute to rtcp-mux-only. P.P.S. Regardless of what we do, we do need the mux exclusive document. Upon more careful re-reading of RFC5761 it looks like it requires for the offerer to provide a fall back RTCP destination when rtcp-mux is not accepted. We need to update the rtcp-mux-exclusive draft to make sure it updates RFC5761 to allow offers without RTCP fallback destination. Regards, _____________ Roman Shpount --047d7bdc08a65cb7fe05300088d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 8, 2016 at 10:39 AM, Flemming Andreasen = <fandreas@cisco.= com> wrote:
Based on all of this, and since we currently have a WG adopted dr= aft for rtcp-mux-exclusive that went through a WGLC already, we want to con= tinue with the rtcp-mux-exclusive solution. If anybody objects to this, ple= ase let us know no later than Friday, April 15.

I support this decision. I always had a preference for rtcp-mux-ex= clusive over anything=C2=A0a=3Drtcp: based since it avoids potential interop issues. I am not sure h= ow existing implementations will react to=C2=A0a=3Drtcp:0. This is something that did no exis= t before and I am not sure if some implementations will not break in unexpe= cted way because of=C2=A0a=3Drtcp:0.=

P.S. If so= me one really cares about the attribute size, we can always shave 5 bytes b= y renaming the attribute to=C2=A0rtcp-mux-only.

=
P.P.S. Regardless of what we do, we do need the mux exclusive document= . Upon more careful re-reading of RFC5761 it looks like it requires for the= offerer to provide a fall back RTCP destination when rtcp-mux is not accep= ted. We need to update the rtcp-mux-exclusive draft to make sure it updates= RFC5761 to allow offers without RTCP fallback destination.

<= /div>
Regards,
_____________Roman Shpount
=C2=A0
--047d7bdc08a65cb7fe05300088d7-- From nobody Tue Apr 12 04:09:47 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C376912DE6E for ; Tue, 12 Apr 2016 04:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQNIUmzR3cuA for ; Tue, 12 Apr 2016 04:09:45 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 578F112DDEB for ; Tue, 12 Apr 2016 04:09:44 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-7f-570cd776419f Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3B.40.12926.677DC075; Tue, 12 Apr 2016 13:09:42 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0248.002; Tue, 12 Apr 2016 13:09:31 +0200 From: Christer Holmberg To: mmusic Thread-Topic: BUNDLE: Text on inclusion of IDENTICAL/TRANSPORT mux category SDP attributes in one m- line only Thread-Index: AdGUq8MkoifPmlCjQReJmhnIgcvq2Q== Date: Tue, 12 Apr 2016 11:09:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F30F4E@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37F30F4EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7pW7ZdZ5wg+azmhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrZF0gVzOxgrbrz+zdrAOKGqi5GTQ0LAROLF95csELaYxIV7 69lAbCGBI4wS898wdjFyAdmLGSUOLX3K1MXIwcEmYCHR/U8bpEZEQEZi76bNzCC2sEC2xJ+D R1kh4gUSBxfsZYKw9SSmLDoNNpNFQFVi6e1bYPW8Ar4SDxufgNUzAu39fmoNWD2zgLjErSfz mSDuEZBYsuc8M4QtKvHy8T9WCFtJonEJRC+zQL7EgRkzmCBmCkqcnPmEZQKj0Cwko2YhKZuF pAwiriOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYhQtTi1Oyk03MtZLLcpMLi7Oz9PLSy3Z xAiMiINbfqvuYLz8xvEQowAHoxIP74IwnnAh1sSy4srcQ4wSHMxKIrztl4FCvCmJlVWpRfnx RaU5qcWHGKU5WJTEebMj/4UJCaQnlqRmp6YWpBbBZJk4OKUaGJ2+bjFYpPSL/83ftXt3l7xk lb2u/kV4A/e6ywv33n/yq/jm/xXf/lzeF7Inz15uik3QcbZZ3/WrVsmcW8TQ5MfZzW+S7eTV lVB7W9svSPHqxcQF7umWZndvSW66nPLmHvv9F0t/7t98SD17VhVT87+upSXzg5g9p7/d4DZT NzPj6Ek5z6KXJyOVWIozEg21mIuKEwG/w9emhAIAAA== Archived-At: Subject: [MMUSIC] BUNDLE: Text on inclusion of IDENTICAL/TRANSPORT mux category SDP attributes in one m- line only X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 12 Apr 2016 11:09:47 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37F30F4EESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi BUNDLE lovers, Based on the agreement that the include-SDP-attributes-in-one-m-line-only a= pplies to ALL IDENTICAL/TRANSPORT mux category SDP attributes (not only ICE= related), I have modified the generic SDP O/A section of BUNDLE. Regards, Christer ------------------------------ 8. SDP Offer/Answer Procedures 8.1. General This section describes the SDP Offer/Answer [RFC3264] procedures for: o Negotiating and creating of a BUNDLE group; and o Selecting the BUNDLE addresses (offerer BUNDLE address and answerer BUNDLE address); and o Adding an "m=3D" line to a BUNDLE group; and o Moving an "m=3D" line out of a BUNDLE group; and o Disabling an "m=3D" line within a BUNDLE group. The generic rules and procedures defined in [RFC3264] and [RFC5888] also apply to the BUNDLE extension. For example, if an offer is rejected by the answerer, the previously negotiated SDP parameters and characteristics (including those associated with a BUNDLE group) apply. Hence, if an offerer generates an offer in which the offerer wants to create a BUNDLE group, and the answerer rejects the offer, the BUNDLE group is not created. The procedures in this section are independent of the media type or "m=3D" line proto value represented by a bundled "m=3D" line. Section 1= 0 defines additional considerations for RTP based media. Section 6 defines additional considerations for the usage of the SDP 'bundle- only' attribute. Section 11 defines additional considerations for the usage of Interactive Connectivity Establishment (ICE) [I-D.ietf-ice-rfc5245bis] mechanism . When an offerer associates a shared address with a bundled "m=3D" line, the offerer shall associate IDENTICAL and TRANSPORT mux category SDP attributes [I-D.ietf-mmusic-sdp-mux-attributes] with the "m=3D" line only if the "m=3D" line is associated with the offerer BUNDLE-tag. Otherwise the offerer MUST NOT associate such SDP attributes with the "m=3D" line. When an answerer associates a shared address with a bundled "m=3D" line, the answerer shall associate IDENTICAL and TRANSPORT category SDP attributes with the "m=3D" line only if the "m=3D" line is associate= d with the answerer BUNDLE-tag. Otherwise the answerer MUST NOT associate such SDP attributes with the "m=3D" line. NOTE: As bundled "m=3D" lines associated with a shared address will share the same IDENTICAL and TRANSPORT mux category SDP attributes, and attribute values, there is no need to associate such SDP attributes with each "m=3D" line. SDP offers and answers can contain multiple BUNDLE groups. The procedures in this section apply independently to a given BUNDLE group. --_000_7594FB04B1934943A5C02806D1A2204B37F30F4EESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi BUNDLE lovers,

 

Based on the agreement that the include-SDP-attribut= es-in-one-m-line-only applies to ALL IDENTICAL/TRANSPORT mux category SDP a= ttributes (not only ICE related), I have modified the generic SDP O/A secti= on of BUNDLE.

 

Regards,

 

Christer

 

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

 

8.  SDP Offer/Answer Proce= dures

 

8.1.  General

 

   This section descr= ibes the SDP Offer/Answer [RFC3264] procedures for:

 

   o  Negotiatin= g and creating of a BUNDLE group; and

 

   o  Selecting = the BUNDLE addresses (offerer BUNDLE address and

      = answerer BUNDLE address); and

 

   o  Adding an = "m=3D" line to a BUNDLE group; and

 

   o  Moving an = "m=3D" line out of a BUNDLE group; and

 

  o  Disabling a= n "m=3D" line within a BUNDLE group.

 

   The generic rules = and procedures defined in [RFC3264] and [RFC5888]

   also apply to the = BUNDLE extension.  For example, if an offer is

   rejected by the an= swerer, the previously negotiated SDP parameters

   and characteristic= s (including those associated with a BUNDLE group)

   apply.  Hence= , if an offerer generates an offer in which the offerer

   wants to create a = BUNDLE group, and the answerer rejects the offer,

   the BUNDLE group i= s not created.

 

   The procedures in = this section are independent of the media type or

   "m=3D" l= ine proto value represented by a bundled "m=3D" line.  Secti= on 10

   defines additional= considerations for RTP based media.  Section 6

   defines additional= considerations for the usage of the SDP 'bundle-

   only' attribute.&n= bsp; Section 11 defines additional considerations for

   the usage of Inter= active Connectivity Establishment (ICE)

   [I-D.ietf-ice-rfc5= 245bis] mechanism .

 

   When an offerer associates a shared address with = a bundled "m=3D" line,

   the offe= rer shall associate IDENTICAL and TRANSPORT mux category SDP

   attribut= es [I-D.ietf-mmusic-sdp-mux-attributes] with the "m=3D" line=

   only if = the "m=3D" line is associated with the offerer BUNDLE-tag.

   Otherwis= e the offerer MUST NOT associate such SDP attributes with the

   "m= =3D" line.

 

   When an = answerer associates a shared address with a bundled "m=3D"

   line, th= e answerer shall associate IDENTICAL and TRANSPORT category

   SDP attr= ibutes with the "m=3D" line only if the "m=3D" line is = associated

   with the= answerer BUNDLE-tag.  Otherwise the answerer MUST NOT

   associat= e such SDP attributes with the "m=3D" line.

 

   NOTE: As= bundled "m=3D" lines associated with a shared address will<= /o:p>

   share th= e same IDENTICAL and TRANSPORT mux category SDP attributes,

   and attr= ibute values, there is no need to associate such SDP

   attribut= es with each "m=3D" line.

 

   SDP offers and ans= wers can contain multiple BUNDLE groups.  The

   procedures in this= section apply independently to a given BUNDLE

   group.<= /span>

 

--_000_7594FB04B1934943A5C02806D1A2204B37F30F4EESESSMB209erics_-- From nobody Thu Apr 14 03:10:41 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0D212DD36; Thu, 14 Apr 2016 03:10:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160414101039.6844.52421.idtracker@ietfa.amsl.com> Date: Thu, 14 Apr 2016 03:10:39 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-28.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 10:10:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-28.txt Pages : 52 Date : 2016-04-14 Abstract: This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single address:port combination (BUNDLE address) for receiving media, referred to as bundled media, specified by multiple SDP media descriptions ("m=" lines). To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. There are multiple ways to correlate the bundled RTP packets with the appropriate media descriptions. This specification defines a new Real-time Transport Protocol (RTP) source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/ RTCP packets with a specific media description. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-28 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-28 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 14 03:14:43 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EF012E188 for ; Thu, 14 Apr 2016 03:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAXewsHwSSJk for ; Thu, 14 Apr 2016 03:14:36 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B61012D86E for ; Thu, 14 Apr 2016 03:14:35 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-f0-570f6d89cac1 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B2.7A.12926.98D6F075; Thu, 14 Apr 2016 12:14:33 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0248.002; Thu, 14 Apr 2016 12:13:54 +0200 From: Christer Holmberg To: mmusic Thread-Topic: Draft new version: BUNDLE-28 Thread-Index: AdGWNf7gxdBOW/dfTqqQtLetZy78hg== Date: Thu, 14 Apr 2016 10:13:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F366C8@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37F366C8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2J7uG5nLn+4QdtNcYupyx+zODB6LFny kymAMYrLJiU1J7MstUjfLoErY1bzS8aCLdIVf1tnMjcwdkh0MXJySAiYSHT8WcAKYYtJXLi3 nq2LkYtDSOAIo8TC6UeYIZzFjBJ/Fx8BquLgYBOwkOj+pw3SICIgI7F302ZmkLCwgKrEgUVV EGEtiWcXTzJB2HoS7yY/BbNZgErOrGoHm8Ir4Csx77s1SJgRaO33U2vASpgFxCVuPZnPBHGO gMSSPeeZIWxRiZeP/0GdqSSx6PZnqPp8iY7f/WA2r4CgxMmZT1gmMArNQjJqFpKyWUjKIOI6 Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypG0eLU4qTcdCNjvdSizOTi4vw8vbzUkk2MwHg4 uOW36g7Gy28cDzEKcDAq8fAmPOANF2JNLCuuzD3EKMHBrCTCa5zNHy7Em5JYWZValB9fVJqT WnyIUZqDRUmcNzvyX5iQQHpiSWp2ampBahFMlomDU6qB0U/8SMgbh2tZRSwrZlRwuU+b5L9G 65/d/RzlBxP81u9c6yaiPK/BtOK6463bS17p5AhtLs6YdF5B8MIVmXbRri6h1yJd3B83nfzB IiB4yuP8/spDOaLPLIQPvfR7+E7F3+zQw4M7Dh/zfNt99Nr0a/YHrJWVRRZ9X/xi3w6dih/l jc94/boEHyixFGckGmoxFxUnAgBvLcv0gwIAAA== Archived-At: Subject: [MMUSIC] Draft new version: BUNDLE-28 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 10:14:41 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37F366C8ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi bundle lovers, I've submitted a new version (-28) of draft-ietf-mmusic-sdp-bundle-negotiat= ion. The draft now specifies that, when a bundled m- line contains a shared= address, TRANSPORT and IDENTICAL mux category attributes are only associat= ed with the m- line associated with the offerer/answererer BUNDLE-tag. Again, I've had to do some text changes, so I encourage everybody to take a= look at the offer/answer sections in the draft (general, mux and ICE). Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37F366C8ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi bundle lovers,

 

I’ve submitted a new version (-28) of draft-ie= tf-mmusic-sdp-bundle-negotiation. The draft now specifies that, when a bund= led m- line contains a shared address, TRANSPORT and IDENTICAL mux category= attributes are only associated with the m- line associated with the offerer/answererer BUNDLE-tag.

 

Again, I’ve had to do some text changes, so I = encourage everybody to take a look at the offer/answer sections in the draf= t (general, mux and ICE).

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37F366C8ESESSMB209erics_-- From nobody Thu Apr 14 11:31:23 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE4112D9CA for ; Thu, 14 Apr 2016 11:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 bZModrezqHoG for ; Thu, 14 Apr 2016 11:31:20 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D01DC12D904 for ; Thu, 14 Apr 2016 11:31:19 -0700 (PDT) X-AuditID: c1b4fb3a-f795d6d000004243-3c-570fe1f5c563 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B5.48.16963.5F1EF075; Thu, 14 Apr 2016 20:31:18 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Thu, 14 Apr 2016 20:30:56 +0200 From: Christer Holmberg To: Roman Shpount , Flemming Andreasen Thread-Topic: [MMUSIC] The way forward wih mux-exclusive Thread-Index: AQHRkaSKAzvOrS1NEUKZX+GpUspZkJ+Ag4GAgAkRLQA= Date: Thu, 14 Apr 2016 18:30:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F37087@ESESSMB209.ericsson.se> References: <5707C2A6.2060001@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37F37087ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUyM2K7nO63h/zhBg3XuS3eX9C1mLr8MYvF jAtTmR2YPab83sjqsWTJTyaPW1MKApijuGxSUnMyy1KL9O0SuDL6f9xmLNhvVvFg9iWWBsaV Bl2MHBwSAiYS3cuDuhg5gUwxiQv31rN1MXJxCAkcYZS4uusuC4SzmFFi94NNbCANbAIWEt3/ tEEaRAT8JO6fvc0MYjMLyEjMONvIBGILC5hL/Jv4ghmixkJi9pKLLBC2lcTvmTvYQGwWAVWJ x1fWgI3kFfCVWHIjHyQsJJAvcbvlMCuIzSkQKLHs+k52EJsR6Lbvp9YwQawSl7j1ZD4TxM0C Ekv2nGeGsEUlXj7+B9YrKqAnseMchC0hoCSx9vB2FojefImuHUfAZvIKCEqcnPmEZQKj2Cwk Y2chKZuFpAwiriOxYPcnNghbW2LZwtfMMPaZA4+heq0llnY+Z0ZWs4CRYxWjaHFqcXFuupGR XmpRZnJxcX6eXl5qySZGYKwe3PLbagfjweeOhxgFOBiVeHgTFvGHC7EmlhVX5h5ilOBgVhLh NbwDFOJNSaysSi3Kjy8qzUktPsQozcGiJM6bE/kvTEggPbEkNTs1tSC1CCbLxMEp1cAots0+ /mn5493TCxkDjp1Ut1/3pGX/7z6fPkuno8tu+Nts///6ioRrWercwpS6tRlFQs8ORD+ey/cr asOVlDURf0tMJN0CNm3tMFQovlHGu/Ftc2hJ6MW8ftOgaDvHu7Xht+bmM1056eynlGh0ObVR 6rlW13KHn+5sLrXRd2JPHm53iVg0J0iJpTgj0VCLuag4EQArfXi90QIAAA== Archived-At: Cc: mmusic Subject: Re: [MMUSIC] The way forward wih mux-exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 18:31:23 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37F37087ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, ... >P.P.S. Regardless of what we do, we do need the mux exclusive document. Up= on more careful re-reading of RFC5761 it looks like it requires for the off= erer to provide a fall back RTCP destination when rtcp-mux is not accepted. That's why I've been saying the whole time - and that's the reason I wrote = mix-exclusive to begin with :) >We need to update the rtcp-mux-exclusive draft to make sure it updates RFC= 5761 to allow offers without RTCP fallback destination. Currently, the draft defines that, in addition to the new attribute, you al= so insert the rtcp-mux attribute. So, if we keep that, I guess we would nee= d to add something to 5761. But, if we ONLY include the new attribute (I got the impression that's what= people prefer), there is no need to update 5761. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37F37087ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-ID: <097BCDF397A0124496954832E8E8DC73@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

 

…

 

>P.P.S. Regardless of what we do, we= do need the mux exclusive document. Upon more careful re-reading of RFC576= 1 it looks like it requires for the offerer to provide a fall back RTCP destination when rtcp-mux is not accepted.

 

That’s why I’ve been saying= the whole time – and that’s the reason I wrote mix-exclusive t= o begin with :)

 

>We need to update the rtcp-mux-excl= usive draft to make sure it updates RFC5761 to allow offers without RTCP fa= llback destination.

 

Currently, the draft defines that, in a= ddition to the new attribute, you also insert the rtcp-mux attribute. So, i= f we keep that, I guess we would need to add something to 5761.

 

But, if we ONLY include the new attribu= te (I got the impression that’s what people prefer), there is no need= to update 5761.

 

Regards,

 

Christer

 

 

--_000_7594FB04B1934943A5C02806D1A2204B37F37087ESESSMB209erics_-- From nobody Thu Apr 14 11:37:54 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7831012DC00 for ; Thu, 14 Apr 2016 11:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 XGRJLosZ-QOJ for ; Thu, 14 Apr 2016 11:37:50 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51F4612DE70 for ; Thu, 14 Apr 2016 11:37:50 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id u185so112559617iod.3 for ; Thu, 14 Apr 2016 11:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=2fb9rne/ZB/jKaPwQayk041IsooDe7PztUitjWjN78E=; b=BTpbKrD2oA07PgII1/hvLP02z6Ix7jAvDb16tamYd7sw4E24VIqXPnMdJtZGPy9YZz bj/6DBGpHjigy/IctuLR11c8ONUrNdpHh1ykURBTMALWdCpREuRMXcQS1i3by4Lw7se8 iGFUraY2TOXI2orzpzt1gCDhLLkcjPKENnlVcUaxsacpWThRnQIUdr3xopKW0vc5ag3G Wo0zsp5kR4iGIsPD8EDqLX5NXOIIjB4P6XNxNKx6l/nOTthYLXDSmXps7kk1W5WyplKy 6siEDBg1fpIcqbvbQIjRgkhivmsqb5ofuUUwM601bBXEWaf+POGWONoJFDEVAqNkP2j4 XYJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2fb9rne/ZB/jKaPwQayk041IsooDe7PztUitjWjN78E=; b=gHLK5EPzg+aEuO7eZVODMTW3pwnkkd7VyyTu2eBfae76dc99HWb2LEhz+jjxZQZvbR w2jMaFruwqHfVsSrJF8t/7U4dlAyNzlT9sk5OvT/EeQjSqIide0GtTh+oezMlkCv8HHJ S69R8e2iGML/sSW15ctF2hU+RnymExNnw2qMWYINCMmgBIgjoso6S44OMGTv5BqWUqAp xmGTqYm6C0A+0RoY9lL9VYjJNgd07joe5UtenMfWE9wm4bw+6Icx5D/PuaGvNcaCq+Ku bjDzQJOnV+1vKC+Fp5RtZri45WFcv+nqzAdA0oO1wpWbiJALCDMlLpqK1u33xHzILIF5 IhuQ== X-Gm-Message-State: AOPr4FXM6ATpH+WFN4hRDdJw9E+D1bkTEkQdvIoGItAxlqqaEw55rLi1owRg1i6U2rOxDw== X-Received: by 10.107.10.144 with SMTP id 16mr19540414iok.48.1460659069719; Thu, 14 Apr 2016 11:37:49 -0700 (PDT) Received: from mail-io0-f170.google.com (mail-io0-f170.google.com. [209.85.223.170]) by smtp.gmail.com with ESMTPSA id fm1sm14561129igb.1.2016.04.14.11.37.48 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2016 11:37:49 -0700 (PDT) Received: by mail-io0-f170.google.com with SMTP id 2so112754556ioy.1 for ; Thu, 14 Apr 2016 11:37:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.30.71 with SMTP id e68mr18340104ioe.145.1460659068610; Thu, 14 Apr 2016 11:37:48 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Thu, 14 Apr 2016 11:37:48 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F37087@ESESSMB209.ericsson.se> References: <5707C2A6.2060001@cisco.com> <7594FB04B1934943A5C02806D1A2204B37F37087@ESESSMB209.ericsson.se> Date: Thu, 14 Apr 2016 14:37:48 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1140d71eec7da705307630cf Archived-At: Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] The way forward wih mux-exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 18:37:52 -0000 --001a1140d71eec7da705307630cf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 14, 2016 at 2:30 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Currently, the draft defines that, in addition to the new attribute, you > also insert the rtcp-mux attribute. So, if we keep that, I guess we would > need to add something to 5761. > > > > But, if we ONLY include the new attribute (I got the impression that=E2= =80=99s > what people prefer), there is no need to update 5761. > > > Agreed. I simply wanted to point out the RFC5761 requires to provide an RTCP fallback when rtcp-mux attribute is used. If RTCP fallback is not provided and if rtcp-mux attribute is used (which we are doing now in rtcp-mux-exclusive), then we must update RFC5761 (which we are not doing now). Regards, _____________ Roman Shpount --001a1140d71eec7da705307630cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 14, 2016 at 2:30 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Currently, the draft defines that, in addition to t= he new attribute, you also insert the rtcp-mux attribute. So, if we keep th= at, I guess we would need to add something to 5761.

=C2=A0

But, if we ONLY include the new attribute (I got th= e impression that=E2=80=99s what people prefer), there is no need to update= 5761.



Agreed. I simply wanted to point out the RFC5761 requires to provide= an RTCP fallback when rtcp-mux attribute is used. If RTCP fallback is not = provided and if rtcp-mux attribute is used (which we are doing now in rtcp-= mux-exclusive), then we must update RFC5761 (which we are not doing now).

Regards,
_= ____________
Roman Shpount
=C2=A0
--001a1140d71eec7da705307630cf-- From nobody Thu Apr 14 12:31:48 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2124112E1C4 for ; Thu, 14 Apr 2016 12:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 GuW7iAKQVp-o for ; Thu, 14 Apr 2016 12:31:45 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D337E12E1C0 for ; Thu, 14 Apr 2016 12:31:44 -0700 (PDT) X-AuditID: c1b4fb3a-f795d6d000004243-78-570ff01ff0a9 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D6.5E.16963.F10FF075; Thu, 14 Apr 2016 21:31:43 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0248.002; Thu, 14 Apr 2016 21:31:42 +0200 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] The way forward wih mux-exclusive Thread-Index: AQHRkaSKAzvOrS1NEUKZX+GpUspZkJ+Ag4GAgAkRLQCAAB/+AIAAMFCg Date: Thu, 14 Apr 2016 19:31:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F3715D@ESESSMB209.ericsson.se> References: <5707C2A6.2060001@cisco.com> <7594FB04B1934943A5C02806D1A2204B37F37087@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37F3715DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7qK78B/5wgzeT+CzeX9C1mLr8MYvF jAtTmR2YPab83sjqsWTJTyaPW1MKApijuGxSUnMyy1KL9O0SuDL2X+piKnjhV/GwZS9bA+MF ny5GTg4JAROJ5de/sULYYhIX7q1n62Lk4hASOMIosXV3KzuEs5hRYtGGA0AZDg42AQuJ7n/a IA0iAqoSf79PZgKxmQVcJRZd2coIYgsLmEt0bZ/KBFFjITF7yUUWCNtN4t2sRjYQmwWo9+yS v2CLeQV8JVa1H2SG2PWLUeLIxm52kF2cAoESWz9ogtQwAh33/dQaqF3iEreezGeCOFpAYsme 88wQtqjEy8f/oJ5Rklh7eDsLRH2+ROOaiSwQuwQlTs58wjKBUXQWklGzkJTNQlI2C+gKZgFN ifW79CFKFCWmdD9kh7A1JFrnzGVHFl/AyL6KUbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzD6 Dm75bbWD8eBzx0OMAhyMSjy8CYv4w4VYE8uKK3MPMUpwMCuJ8Lq9AgrxpiRWVqUW5ccXleak Fh9ilOZgURLnzYn8FyYkkJ5YkpqdmlqQWgSTZeLglGpgtGuX4HHVzDl/Z/UuGfObWtKTS14v 0XfrNToysbfGSX3Lpw8z2RRYdkUVKa95odkuzPGmZlFMS+N9joyzH7kLC3OV3TO/csT/N9Fm UTwVneSeOSnkjm7rxu2sWa8yMgTelPwT23aqi7k80z9Tpzk8YN/eBxc2bvOc2PzoQk9t0e3b mZzxLQFKLMUZiYZazEXFiQCvh7OyugIAAA== Archived-At: Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] The way forward wih mux-exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 19:31:47 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37F3715DESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClNvLCB1bmxlc3Mgc29tZW9uZSBvYmplY3RzLCBJ4oCZbGwgcmVtb3ZlIHRoZSB1c2Fn ZSBvZiB0aGUgcnRjcC1tdXggYXR0cmlidXRlLCBhbmQgbXV4IGV4Y2x1c2l2ZSB3aWxsIGJlIGlu ZGljYXRlZCB1c2luZyB0aGUgbmV3IGF0dHJpYnV0ZSBvbmx5Lg0KDQpSZWdhcmRzLA0KDQpDaHJp c3Rlcg0KDQpGcm9tOiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJpeC5jb21dDQpT ZW50OiAxNCBBcHJpbCAyMDE2IDIxOjM4DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCkNjOiBGbGVtbWluZyBBbmRyZWFzZW4gPGZhbmRyZWFz QGNpc2NvLmNvbT47IG1tdXNpYyA8bW11c2ljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtNTVVT SUNdIFRoZSB3YXkgZm9yd2FyZCB3aWggbXV4LWV4Y2x1c2l2ZQ0KDQpPbiBUaHUsIEFwciAxNCwg MjAxNiBhdCAyOjMwIFBNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToN CkN1cnJlbnRseSwgdGhlIGRyYWZ0IGRlZmluZXMgdGhhdCwgaW4gYWRkaXRpb24gdG8gdGhlIG5l dyBhdHRyaWJ1dGUsIHlvdSBhbHNvIGluc2VydCB0aGUgcnRjcC1tdXggYXR0cmlidXRlLiBTbywg aWYgd2Uga2VlcCB0aGF0LCBJIGd1ZXNzIHdlIHdvdWxkIG5lZWQgdG8gYWRkIHNvbWV0aGluZyB0 byA1NzYxLg0KDQpCdXQsIGlmIHdlIE9OTFkgaW5jbHVkZSB0aGUgbmV3IGF0dHJpYnV0ZSAoSSBn b3QgdGhlIGltcHJlc3Npb24gdGhhdOKAmXMgd2hhdCBwZW9wbGUgcHJlZmVyKSwgdGhlcmUgaXMg bm8gbmVlZCB0byB1cGRhdGUgNTc2MS4NCg0KDQpBZ3JlZWQuIEkgc2ltcGx5IHdhbnRlZCB0byBw b2ludCBvdXQgdGhlIFJGQzU3NjEgcmVxdWlyZXMgdG8gcHJvdmlkZSBhbiBSVENQIGZhbGxiYWNr IHdoZW4gcnRjcC1tdXggYXR0cmlidXRlIGlzIHVzZWQuIElmIFJUQ1AgZmFsbGJhY2sgaXMgbm90 IHByb3ZpZGVkIGFuZCBpZiBydGNwLW11eCBhdHRyaWJ1dGUgaXMgdXNlZCAod2hpY2ggd2UgYXJl IGRvaW5nIG5vdyBpbiBydGNwLW11eC1leGNsdXNpdmUpLCB0aGVuIHdlIG11c3QgdXBkYXRlIFJG QzU3NjEgKHdoaWNoIHdlIGFyZSBub3QgZG9pbmcgbm93KS4NCg0KUmVnYXJkcywNCl9fX19fX19f X19fX18NClJvbWFuIFNocG91bnQNCg0K --_000_7594FB04B1934943A5C02806D1A2204B37F3715DESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlNvLCB1bmxlc3Mgc29tZW9uZSBvYmplY3RzLCBJ4oCZ bGwgcmVtb3ZlIHRoZSB1c2FnZSBvZiB0aGUgcnRjcC1tdXggYXR0cmlidXRlLCBhbmQgbXV4IGV4 Y2x1c2l2ZSB3aWxsIGJlIGluZGljYXRlZCB1c2luZyB0aGUgbmV3IGF0dHJpYnV0ZQ0KIG9ubHku PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJpeC5j b21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMTQgQXByaWwgMjAxNiAyMTozODxicj4NCjxiPlRvOjwv Yj4gQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZn dDs8YnI+DQo8Yj5DYzo8L2I+IEZsZW1taW5nIEFuZHJlYXNlbiAmbHQ7ZmFuZHJlYXNAY2lzY28u Y29tJmd0OzsgbW11c2ljICZsdDttbXVzaWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbTU1VU0lDXSBUaGUgd2F5IGZvcndhcmQgd2loIG11eC1leGNsdXNpdmU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBU aHUsIEFwciAxNCwgMjAxNiBhdCAyOjMwIFBNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Q3VycmVu dGx5LCB0aGUgZHJhZnQgZGVmaW5lcyB0aGF0LCBpbiBhZGRpdGlvbiB0byB0aGUgbmV3IGF0dHJp YnV0ZSwgeW91IGFsc28gaW5zZXJ0IHRoZSBydGNwLW11eCBhdHRyaWJ1dGUuDQogU28sIGlmIHdl IGtlZXAgdGhhdCwgSSBndWVzcyB3ZSB3b3VsZCBuZWVkIHRvIGFkZCBzb21ldGhpbmcgdG8gNTc2 MS48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5CdXQs IGlmIHdlIE9OTFkgaW5jbHVkZSB0aGUgbmV3IGF0dHJpYnV0ZSAoSSBnb3QgdGhlIGltcHJlc3Np b24gdGhhdOKAmXMgd2hhdCBwZW9wbGUgcHJlZmVyKSwgdGhlcmUgaXMNCiBubyBuZWVkIHRvIHVw ZGF0ZSA1NzYxLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ3JlZWQu IEkgc2ltcGx5IHdhbnRlZCB0byBwb2ludCBvdXQgdGhlIFJGQzU3NjEgcmVxdWlyZXMgdG8gcHJv dmlkZSBhbiBSVENQIGZhbGxiYWNrIHdoZW4gcnRjcC1tdXggYXR0cmlidXRlIGlzIHVzZWQuIElm IFJUQ1AgZmFsbGJhY2sgaXMgbm90IHByb3ZpZGVkIGFuZCBpZiBydGNwLW11eCBhdHRyaWJ1dGUg aXMgdXNlZCAod2hpY2ggd2UgYXJlIGRvaW5nIG5vdyBpbiBydGNwLW11eC1leGNsdXNpdmUpLCB0 aGVuDQogd2UgbXVzdCB1cGRhdGUgUkZDNTc2MSAod2hpY2ggd2UgYXJlIG5vdCBkb2luZyBub3cp LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B37F3715DESESSMB209erics_-- From nobody Thu Apr 14 12:49:07 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2DE12E0AF for ; Thu, 14 Apr 2016 12:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 ZrY_o6Z72wnU for ; Thu, 14 Apr 2016 12:49:03 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3C9512DD40 for ; Thu, 14 Apr 2016 12:49:02 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id g185so114651811ioa.2 for ; Thu, 14 Apr 2016 12:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=YzvYs5uWIxKC0uycs+X40wqbZu3hl249mw8nhI0DJMI=; b=txQZ/OSoC9recXcfiSCyFwostZLExzn3U4L9vrHy6b6Jp5c9vjbr81BMqbuV4IHpio Cc5k/PA7j94rBdmHjStn6QxcWrHf1yZ5bX2L4YRyDrfY4TRR3rk0beZvNTpugZlAp8Ut 4uNgz1evUFthfhoL3+Fcncp/f77CA0P11gJK9UaTrPKhgkz2eF8X9v2BZED/U8MXHaau IgSGoBaesoMPvgBzGJlIFn9k6SttCZQyFkKrsUbq72XWi+JM133dmui/uNThUiG/XXkP UxBMBDWc4cKG5DNtiRbElSiSCEcJTcoHrFHMmgc7zwLc2OuD6rJvgsIJnua/r6hQxS1J aQoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=YzvYs5uWIxKC0uycs+X40wqbZu3hl249mw8nhI0DJMI=; b=b0RMJBzQND7GD/mNgBSUZbdNh229CVj4kTf0UVqu9pA5VJ8ZP7kIQXzRGEU1t5l+3L HD1LQ5PPXOjhJpbYhhAtLS3QCUvEuUCSZssaGLMc9Cb5s4Pl9+H7Ukn9G44I5qWwapze TRvlWbrisxiCibs7/3VFEmRpQA0gITqQVxhuF0/WQBNrG5dZmvwt5yaBcpnGI5f4ZcKi lA3XdPwwhdoGZQBvR5GwweVSyOiOWEOkDlZHp7LwQMCofle8TcDRp0b4U/+yeaM4OXLY 8eAwl7cSw9cBwYt+ydwMX4FRe5qRBbK9Wn7Ci8/bGpNSU6iEJdZXNExnQ6fv0UUKXKw6 y16g== X-Gm-Message-State: AOPr4FUdZZ4dGPaYuWLMxaLVprpIPuC6tCdLFrWGxd64u8W42AYIHdQI3li3S/FjM4M1jA== X-Received: by 10.107.173.69 with SMTP id w66mr20064851ioe.182.1460663342257; Thu, 14 Apr 2016 12:49:02 -0700 (PDT) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com. [209.85.223.169]) by smtp.gmail.com with ESMTPSA id cj5sm3808122igc.1.2016.04.14.12.49.01 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2016 12:49:01 -0700 (PDT) Received: by mail-io0-f169.google.com with SMTP id u185so114528948iod.3 for ; Thu, 14 Apr 2016 12:49:01 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.30.71 with SMTP id e68mr18682754ioe.145.1460663341327; Thu, 14 Apr 2016 12:49:01 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Thu, 14 Apr 2016 12:49:01 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F3715D@ESESSMB209.ericsson.se> References: <5707C2A6.2060001@cisco.com> <7594FB04B1934943A5C02806D1A2204B37F37087@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F3715D@ESESSMB209.ericsson.se> Date: Thu, 14 Apr 2016 15:49:01 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1140d71e98c09d0530772fd3 Archived-At: Cc: mmusic Subject: Re: [MMUSIC] The way forward wih mux-exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 19:49:06 -0000 --001a1140d71e98c09d0530772fd3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This can currently produce interop problems. With current usage, if rtcp-mux is supported by the remote end point, it will correctly negotiate with rtcp-mux-exclusive. If you remove rtcp-mux attribute from the offer, connection will not be established. This will be especially important during the migration from rtcp-mux to rtcp-mux-exclusive for current implementations. Only inserting rtcp-mux-exclusive, of cause, is better long term, since it is removing redundant information from SDP. Also, does anybody want to rename rtcp-mux-exclusive to rtcp-mux-only? This is shorter and more inline with typical naming convention for such attributes. Regards, _____________ Roman Shpount On Thu, Apr 14, 2016 at 3:31 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > So, unless someone objects, I=E2=80=99ll remove the usage of the rtcp-mux > attribute, and mux exclusive will be indicated using the new attribute on= ly. > > > > Regards, > > > > Christer > > > > *From:* Roman Shpount [mailto:roman@telurix.com] > *Sent:* 14 April 2016 21:38 > *To:* Christer Holmberg > *Cc:* Flemming Andreasen ; mmusic > *Subject:* Re: [MMUSIC] The way forward wih mux-exclusive > > > > On Thu, Apr 14, 2016 at 2:30 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Currently, the draft defines that, in addition to the new attribute, you > also insert the rtcp-mux attribute. So, if we keep that, I guess we would > need to add something to 5761. > > > > But, if we ONLY include the new attribute (I got the impression that=E2= =80=99s > what people prefer), there is no need to update 5761. > > > > > > Agreed. I simply wanted to point out the RFC5761 requires to provide an > RTCP fallback when rtcp-mux attribute is used. If RTCP fallback is not > provided and if rtcp-mux attribute is used (which we are doing now in > rtcp-mux-exclusive), then we must update RFC5761 (which we are not doing > now). > > > > Regards, > > _____________ > Roman Shpount > > > --001a1140d71e98c09d0530772fd3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This can currently produce interop problems. With current = usage, if rtcp-mux is supported by the remote end point, it will correctly = negotiate with rtcp-mux-exclusive. If you remove rtcp-mux attribute from th= e offer, connection will not be established. This will be especially import= ant during the migration from rtcp-mux to rtcp-mux-exclusive for current im= plementations. Only inserting=C2=A0rtcp-mux-exclusive, of cause, is better = long term, since it is=C2=A0removing redundant information from SDP.
Also, does anybody want to rename rtcp-mux-exclusive to rtcp-m= ux-only? This is shorter and more inline with typical naming convention for= such attributes.

Regards,
___= __________
Roman Shpount

On Thu, Apr 14, 2016 at 3:31 PM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>

Hi,

=C2=A0

So, unless someone objects, I=E2=80=99ll rem= ove the usage of the rtcp-mux attribute, and mux exclusive will be indicate= d using the new attribute only.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: Roman Shpount [mailto:roman@telurix.com]
Sent: 14 April 2016 21:38
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Flemming Andreasen <fandreas@cisco.com>; mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] The way forward wih mux-exclusive

=C2=A0

On Thu, Apr 14, 2016 at 2:30 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Currently, the draft defines that, in addition to t= he new attribute, you also insert the rtcp-mux attribute. So, if we keep that, I guess we would need to add something to 5761.

=C2=A0

But, if we ONLY include the new attribute (I got th= e impression that=E2=80=99s what people prefer), there is no need to update 5761.

=C2=A0

=C2=A0

Agreed. I simply wanted to point out the RFC5761 req= uires to provide an RTCP fallback when rtcp-mux attribute is used. If RTCP = fallback is not provided and if rtcp-mux attribute is used (which we are do= ing now in rtcp-mux-exclusive), then we must update RFC5761 (which we are not doing now).

=C2=A0

Regards,

_____________
Roman Shpount

=C2=A0


--001a1140d71e98c09d0530772fd3-- From nobody Thu Apr 14 13:00:53 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB0112E1D4 for ; Thu, 14 Apr 2016 13:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 ua3_KzYBBS04 for ; Thu, 14 Apr 2016 13:00:49 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C6612DEF1 for ; Thu, 14 Apr 2016 13:00:49 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by comcast with SMTP id qnQvaGWkQjuYRqnRYay6sU; Thu, 14 Apr 2016 20:00:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460664048; bh=RTsRvPCVF9mcp/PuP7Hakjvy2z3hPP3pWsPVg48zYgM=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=U3/Rxmh3IyXFbcZEkzcpix4Av3q/HN0eUKdOV/rSa2th5TcwHTQSNggwqvwjIQh3N wgj6VdSPaiInnpUUcByW7yLleMAncoqvWx7b8pbF1nPVSqrmaXk/HMtK5u59qF8rTE 6IRDqE/ssLui9HrfPI2rocJZrY8+IyFb0h25z6aWalPpNnUPOOGEtFQ6LhTbtEapCH eHxxRjktmfRQ2Z2lGHSg95/9wenvOnHWJKrYyKQg+z+YgDlqsPacXS2scetzuaM2Gx rnc24vsKuUuVGgjBCsB79vO56eppr2d8SqkrrZP5RAmi/fzwTkOlrM81TfAq2WDoFX ZbGWWvVeiksug== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-13v.sys.comcast.net with comcast id iL0o1s00A3KdFy101L0ozj; Thu, 14 Apr 2016 20:00:48 +0000 To: mmusic@ietf.org References: <5707C2A6.2060001@cisco.com> <7594FB04B1934943A5C02806D1A2204B37F37087@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F3715D@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <570FF6EF.7020308@alum.mit.edu> Date: Thu, 14 Apr 2016 16:00:47 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MMUSIC] The way forward wih mux-exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 20:00:51 -0000 On 4/14/16 3:49 PM, Roman Shpount wrote: > This can currently produce interop problems. With current usage, if > rtcp-mux is supported by the remote end point, it will correctly > negotiate with rtcp-mux-exclusive. If you remove rtcp-mux attribute from > the offer, connection will not be established. This will be especially > important during the migration from rtcp-mux to rtcp-mux-exclusive for > current implementations. Only inserting rtcp-mux-exclusive, of cause, is > better long term, since it is removing redundant information from SDP. So, why not remove use of rtcp-mux as a *requirement* and leave it as an implementation tactic for migration? > Also, does anybody want to rename rtcp-mux-exclusive to rtcp-mux-only? > This is shorter and more inline with typical naming convention for such > attributes. Yes, I like it better. Thanks, Paul > Regards, > _____________ > Roman Shpount > > On Thu, Apr 14, 2016 at 3:31 PM, Christer Holmberg > > > wrote: > > Hi,____ > > __ __ > > So, unless someone objects, Ill remove the usage of the rtcp-mux > attribute, and mux exclusive will be indicated using the new > attribute only.____ > > __ __ > > Regards,____ > > __ __ > > Christer____ > > __ __ > > *From:*Roman Shpount [mailto:roman@telurix.com > ] > *Sent:* 14 April 2016 21:38 > *To:* Christer Holmberg > > *Cc:* Flemming Andreasen >; mmusic > > *Subject:* Re: [MMUSIC] The way forward wih mux-exclusive____ > > __ __ > > On Thu, Apr 14, 2016 at 2:30 PM, Christer Holmberg > > wrote:____ > > Currently, the draft defines that, in addition to the new > attribute, you also insert the rtcp-mux attribute. So, if we > keep that, I guess we would need to add something to 5761.____ > > ____ > > But, if we ONLY include the new attribute (I got the impression > thats what people prefer), there is no need to update 5761.____ > > __ __ > > __ __ > > Agreed. I simply wanted to point out the RFC5761 requires to provide > an RTCP fallback when rtcp-mux attribute is used. If RTCP fallback > is not provided and if rtcp-mux attribute is used (which we are > doing now in rtcp-mux-exclusive), then we must update RFC5761 (which > we are not doing now).____ > > __ __ > > Regards,____ > > _____________ > Roman Shpount____ > > ____ > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Thu Apr 14 13:10:04 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB9112D6A6 for ; Thu, 14 Apr 2016 13:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 DMGKF7Db05G5 for ; Thu, 14 Apr 2016 13:10:01 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA8312D5FE for ; Thu, 14 Apr 2016 13:10:01 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id 2so115290568ioy.1 for ; Thu, 14 Apr 2016 13:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=DtCU5hD+3BhWyMEJbxmu/77qhxsxavHH27SH8kxs7xw=; b=wPubyqcv4deqSvFEL9/Vc/5kqC+NJjIbauRA4rkOOrnyKNfo28eNMW2tHWWdbvB17O ut+NVyciizGYKNoM4HvxrQuMbvweybUDxspB4qTr8VRRtHcxbLYzKiKR5+l5V9owsxJ6 d73lQqAgE3nYakcR8MwUlEw4Xmg5oJsBVO8gmKNqQrRpiZIwty9X2NgZixuI5WY96pF3 xXhpANglTZlxP73AMx8yIuYCn430zthJI+Cq9TI/UxgtkVH7QawiBy9euuBptKBNguGC wdJ4PFTz38358nQ0HV66QOStXswgmgWdaTm3qgEPWsbs7Na37qw+g9Csa44vGXPdl0Gl Ihtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=DtCU5hD+3BhWyMEJbxmu/77qhxsxavHH27SH8kxs7xw=; b=CecBKNRxH0o3zD26wVma1S62GfEUbcq/4pa0DVn+GqMHoOdNXGNVqct/nSlagWkcT/ TLffi8NgOR0ILBlCIUNxlQcqyMfAdQ0A8x0W8l6z32Xt+tkdr9M3NIN8C996lSNXVZoF a9pkDDbJoR7w0X15N5j9FXs8y0+dBw4DMCGnlRcnCOltTF46NkpR8xIVpl8Bzr3Dkuge s6cNrv6TOYgxWa2UCeB6ubV64tB1omAfa7YcHLydCdbD4z/w+qFBELemv0+zxfMXCn7S mTfVqrLLvURJ28g+7RPHFW86MnwdyBznjASWVg/H5+Af8bMEWba7WW7aBgqVxzLFrygJ X9iQ== X-Gm-Message-State: AOPr4FUWTWvOOa+t88vnZQ8664NCM4eB7UjtLCzFqM7CTV3g/Rpm2YoLv6+qtmilOOVruw== X-Received: by 10.107.47.167 with SMTP id v39mr18009341iov.89.1460664600429; Thu, 14 Apr 2016 13:10:00 -0700 (PDT) Received: from mail-io0-f170.google.com (mail-io0-f170.google.com. [209.85.223.170]) by smtp.gmail.com with ESMTPSA id q198sm26094198iod.6.2016.04.14.13.09.59 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2016 13:10:00 -0700 (PDT) Received: by mail-io0-f170.google.com with SMTP id o126so115353227iod.0 for ; Thu, 14 Apr 2016 13:09:59 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.30.71 with SMTP id e68mr18779016ioe.145.1460664599698; Thu, 14 Apr 2016 13:09:59 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Thu, 14 Apr 2016 13:09:59 -0700 (PDT) In-Reply-To: <570FF6EF.7020308@alum.mit.edu> References: <5707C2A6.2060001@cisco.com> <7594FB04B1934943A5C02806D1A2204B37F37087@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F3715D@ESESSMB209.ericsson.se> <570FF6EF.7020308@alum.mit.edu> Date: Thu, 14 Apr 2016 16:09:59 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a1140d71e9a20550530777af0 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] The way forward wih mux-exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 20:10:03 -0000 --001a1140d71e9a20550530777af0 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 14, 2016 at 4:00 PM, Paul Kyzivat wrote: > On 4/14/16 3:49 PM, Roman Shpount wrote: > >> This can currently produce interop problems. With current usage, if >> rtcp-mux is supported by the remote end point, it will correctly >> negotiate with rtcp-mux-exclusive. If you remove rtcp-mux attribute from >> the offer, connection will not be established. This will be especially >> important during the migration from rtcp-mux to rtcp-mux-exclusive for >> current implementations. Only inserting rtcp-mux-exclusive, of cause, is >> better long term, since it is removing redundant information from SDP. >> > > So, why not remove use of rtcp-mux as a *requirement* and leave it as an > implementation tactic for migration? I would be happy to remove this as a "requirement". Specify that it can be optionally used during the migration. But if we do this we will need to update RFC5761, since rtcp-mux will be used without RTCP fallback address being provided (which is required by RFC5761). _____________ Roman Shpount --001a1140d71e9a20550530777af0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 14, 2016 at 4:00 PM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:
On 4/14/16 3:49 PM, Roman Shpount wrote:
This can currently produce interop problems. With current usage, if
rtcp-mux is supported by the remote end point, it will correctly
negotiate with rtcp-mux-exclusive. If you remove rtcp-mux attribute from the offer, connection will not be established. This will be especially
important during the migration from rtcp-mux to rtcp-mux-exclusive for
current implementations. Only inserting rtcp-mux-exclusive, of cause, is better long term, since it is removing redundant information from SDP.

 So, why not remove use of rtcp-mux as a *requirement* and leave it as an im= plementation tactic for migration?

I would = be happy to remove this as a "requirement". Specify that it can b= e optionally used during the migration. But if we do this we will need to u= pdate RFC5761, since rtcp-mux will be used without RTCP fallback address be= ing provided (which is required by RFC5761).
_____________
Roman Shpount
=C2=A0
--001a1140d71e9a20550530777af0-- From nobody Thu Apr 14 13:19:35 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40EEF12DA2B for ; Thu, 14 Apr 2016 13:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 r7JQbV16juKA for ; Thu, 14 Apr 2016 13:19:33 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A4B812D8E4 for ; Thu, 14 Apr 2016 13:19:30 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by comcast with SMTP id qnhPaGYQdjuYRqnjdayBa7; Thu, 14 Apr 2016 20:19:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460665169; bh=z6p9DhP++b5Uj8IxisTZOy4JVcfNFFyK7OcNO+svpec=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=ocNEUvYN++PhwPs+Wmw03IxwzY+WEHh4csN/ASYNaA8PISRlFg0A+fLj5fBEfsW4h JcZplDI6hwr2DMEVOc4XB7Nj8+uVXy9BwWYRN8T9sOcRMWwfWPdnyxB3ENSQC4v1hl 2sF7iKGGmmpH+ry6+64w+xrDI+PO6r9QtLgMKKMYiadXEH2AkWbq4S/RDnJvEVZKkH E5hfh6VQ3pHhEu3I8NdV6wFcKAsrEsy9xK3vVfTVs4hq3yfnuXMsYTtz3YJotCc0xx m3wLg+FeCMtwvldCfthrVZJnKhN3qGWV3+TfbpL195SOvagCacK+l5M0yCy/aHaZBs sWBiX/4s/FTfA== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-16v.sys.comcast.net with comcast id iLKV1s0083KdFy101LKVRp; Thu, 14 Apr 2016 20:19:29 +0000 To: Roman Shpount References: <5707C2A6.2060001@cisco.com> <7594FB04B1934943A5C02806D1A2204B37F37087@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F3715D@ESESSMB209.ericsson.se> <570FF6EF.7020308@alum.mit.edu> From: Paul Kyzivat Message-ID: <570FFB50.6000904@alum.mit.edu> Date: Thu, 14 Apr 2016 16:19:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] The way forward wih mux-exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 20:19:34 -0000 On 4/14/16 4:09 PM, Roman Shpount wrote: > On Thu, Apr 14, 2016 at 4:00 PM, Paul Kyzivat > wrote: > > On 4/14/16 3:49 PM, Roman Shpount wrote: > > This can currently produce interop problems. With current usage, if > rtcp-mux is supported by the remote end point, it will correctly > negotiate with rtcp-mux-exclusive. If you remove rtcp-mux > attribute from > the offer, connection will not be established. This will be > especially > important during the migration from rtcp-mux to > rtcp-mux-exclusive for > current implementations. Only inserting rtcp-mux-exclusive, of > cause, is > better long term, since it is removing redundant information > from SDP. > > > So, why not remove use of rtcp-mux as a *requirement* and leave it > as an implementation tactic for migration? > > > I would be happy to remove this as a "requirement". Specify that it can > be optionally used during the migration. But if we do this we will need > to update RFC5761, since rtcp-mux will be used without RTCP fallback > address being provided (which is required by RFC5761). I guess that "depends". If there is a normative statement about it (even MAY) then I guess you are right. OTOH, maybe not if there is just a note about it, explaining that it it technically a non-conforming usage, and discussing the pros/cons of doing so. Thanks, Paul From nobody Fri Apr 15 00:57:40 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368D012E80B for ; Fri, 15 Apr 2016 00:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sa6VRcbFbmFZ for ; Fri, 15 Apr 2016 00:57:35 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B8EF12E810 for ; Fri, 15 Apr 2016 00:57:04 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-c4-57109ece3578 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 78.58.12926.ECE90175; Fri, 15 Apr 2016 09:57:02 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0248.002; Fri, 15 Apr 2016 09:56:41 +0200 From: Christer Holmberg To: Paul Kyzivat , Roman Shpount Thread-Topic: [MMUSIC] The way forward wih mux-exclusive Thread-Index: AQHRkaSKAzvOrS1NEUKZX+GpUspZkJ+Ag4GAgAkRLQCAAB/+AIAAMFCg///jlYCAAANKgIAAApKAgAACpgCAAPVFgA== Date: Fri, 15 Apr 2016 07:56:40 +0000 Message-ID: References: <5707C2A6.2060001@cisco.com> <7594FB04B1934943A5C02806D1A2204B37F37087@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F3715D@ESESSMB209.ericsson.se> <570FF6EF.7020308@alum.mit.edu> <570FFB50.6000904@alum.mit.edu> In-Reply-To: <570FFB50.6000904@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9A8AD005AA83A24CBA64AD83A40A8D88@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUyM2K7uu65eQLhBq8b1CymLn/MYrFiwwFW ixkXpjI7MHv8ff+ByWPJkp9MHremFAQwR3HZpKTmZJalFunbJXBlLJ6/jbFgj1DF+86LjA2M y/i6GDk5JARMJNo63jFB2GISF+6tZ+ti5OIQEjjCKLFt43oWCGcxo8TP23+Zuxg5ONgELCS6 /2mDNIgIeEtMmL+aDSTMLKAucXVxEEhYWMBc4t/EF8wQJRYSs5dcZIGwsyR6l75kA7FZBFQl nnU2M4G08gpYSax4JQGxaQKLxLSJ58BqOAV0JI43TQKzGYFu+35qDdidzALiEreezIe6WUBi yZ7zzBC2qMTLx/9YQWxRAT2JHedAbA6guJLEtK1pEK16EjemTmGDsK0lzp+HsbUlli18DTaG V0BQ4uTMJywTGCVmIdk2C0n7LCTts5C0z0LSvoCRdRWjaHFqcVJuupGxXmpRZnJxcX6eXl5q ySZGYFQe3PJbdQfj5TeOhxgFOBiVeHgTmgXChVgTy4orcw8xSnAwK4nwys8FCvGmJFZWpRbl xxeV5qQWH2KU5mBREufNjvwXJiSQnliSmp2aWpBaBJNl4uCUamAs4V+/MGTT54euLJfljT6e CVEI9juX+lfjiCrXg0XpcpKJbP6q/AkeioXvz20J3f6ycXdSwFc3Jv5pzzzeavxYnrXx95bv VvLfNH7w1e37MkdGLfJFwR+xuboHmjZNY5lkZPzhhsLqRFEznddsLarWS0IvGu5KaF8ecLpz Kl/Sp78XO/YKFTQqsRRnJBpqMRcVJwIAXR4UtMYCAAA= Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] The way forward wih mux-exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 07:57:38 -0000 Hi, First, I am ok to rename the attribute, in order to make it shorter. Roman has suggested the name change a few times already, and nobody has objected, so I=B9ll change it in the next version of the draft. Second, if we also allow =B3a=3Drtcp-mux=B2, I guess we would need to updat= e 5761 by saying something like: =B3By default, the sender of the attribute must be used with RTCP fallback, unless another mechanism is used to indicate that such fallback is not supported.=B2 Regards, Christer On 14/04/16 23:19, "mmusic on behalf of Paul Kyzivat" wrote: >On 4/14/16 4:09 PM, Roman Shpount wrote: >> On Thu, Apr 14, 2016 at 4:00 PM, Paul Kyzivat > > wrote: >> >> On 4/14/16 3:49 PM, Roman Shpount wrote: >> >> This can currently produce interop problems. With current >>usage, if >> rtcp-mux is supported by the remote end point, it will correctly >> negotiate with rtcp-mux-exclusive. If you remove rtcp-mux >> attribute from >> the offer, connection will not be established. This will be >> especially >> important during the migration from rtcp-mux to >> rtcp-mux-exclusive for >> current implementations. Only inserting rtcp-mux-exclusive, of >> cause, is >> better long term, since it is removing redundant information >> from SDP. >> >> >> So, why not remove use of rtcp-mux as a *requirement* and leave it >> as an implementation tactic for migration? >> >> >> I would be happy to remove this as a "requirement". Specify that it can >> be optionally used during the migration. But if we do this we will need >> to update RFC5761, since rtcp-mux will be used without RTCP fallback >> address being provided (which is required by RFC5761). > >I guess that "depends". If there is a normative statement about it (even >MAY) then I guess you are right. OTOH, maybe not if there is just a note >about it, explaining that it it technically a non-conforming usage, and >discussing the pros/cons of doing so. > > Thanks, > Paul > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Apr 15 07:50:43 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE9412DE9C for ; Fri, 15 Apr 2016 07:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 wd1MHA4GVoRg for ; Fri, 15 Apr 2016 07:50:39 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76B1B12DD7A for ; Fri, 15 Apr 2016 07:50:39 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by comcast with SMTP id r54Oar0zNVEtur54waDdN3; Fri, 15 Apr 2016 14:50:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460731838; bh=eN+xDfYYUAqCDQrHDSOHb2/vUTQtsw3NevYihY40v20=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Ptfz9LeyQy/rRy+8T6p++iMd7V/kaIAsLhBeBpEZG97civn/G+/vyqMteayZ6AIJW QoH2pVsy12jnaZcKdB60LKlCyaF00dH93DCjp9KhEwJ3PxOUukvL8x+QgoZ1M6RBD2 ppJtb4TjMwjDgTzOilBCBH6fSJSKuCt47LKJHrN0GAHDWHALjxXT5i6jwVBVK3ZEoN zY0Uvu/MBO35eRbVX24KWWmVrKQo0loPnvwIjoTfOaTDOf+EPNToNSa8HhL4c+DPlT k0sKTciRNlerYNtYggvHcvi218wrC2MIH9KIMYu29Oz+CIAZbYT4yFumrDyCqhDIb5 iAE6o63kBFEog== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-14v.sys.comcast.net with comcast id ieqe1s0033KdFy101eqe44; Fri, 15 Apr 2016 14:50:38 +0000 To: Christer Holmberg , Roman Shpount References: <5707C2A6.2060001@cisco.com> <7594FB04B1934943A5C02806D1A2204B37F37087@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F3715D@ESESSMB209.ericsson.se> <570FF6EF.7020308@alum.mit.edu> <570FFB50.6000904@alum.mit.edu> From: Paul Kyzivat Message-ID: <5710FFBD.6090504@alum.mit.edu> Date: Fri, 15 Apr 2016 10:50:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] The way forward wih mux-exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 14:50:41 -0000 On 4/15/16 3:56 AM, Christer Holmberg wrote: > > Hi, > > First, I am ok to rename the attribute, in order to make it shorter. Roman > has suggested the name change a few times already, and nobody has > objected, so Ill change it in the next version of the draft. > > Second, if we also allow a=rtcp-mux, I guess we would need to update > 5761 by saying something like: > > By default, the sender of the attribute must be used with RTCP fallback, > unless another mechanism is used to indicate that such fallback is not > supported. That seems like a good way to handle it. Thanks, Paul > Regards, > > Christer > > > > On 14/04/16 23:19, "mmusic on behalf of Paul Kyzivat" > wrote: > >> On 4/14/16 4:09 PM, Roman Shpount wrote: >>> On Thu, Apr 14, 2016 at 4:00 PM, Paul Kyzivat >> > wrote: >>> >>> On 4/14/16 3:49 PM, Roman Shpount wrote: >>> >>> This can currently produce interop problems. With current >>> usage, if >>> rtcp-mux is supported by the remote end point, it will correctly >>> negotiate with rtcp-mux-exclusive. If you remove rtcp-mux >>> attribute from >>> the offer, connection will not be established. This will be >>> especially >>> important during the migration from rtcp-mux to >>> rtcp-mux-exclusive for >>> current implementations. Only inserting rtcp-mux-exclusive, of >>> cause, is >>> better long term, since it is removing redundant information >>> from SDP. >>> >>> >>> So, why not remove use of rtcp-mux as a *requirement* and leave it >>> as an implementation tactic for migration? >>> >>> >>> I would be happy to remove this as a "requirement". Specify that it can >>> be optionally used during the migration. But if we do this we will need >>> to update RFC5761, since rtcp-mux will be used without RTCP fallback >>> address being provided (which is required by RFC5761). >> >> I guess that "depends". If there is a normative statement about it (even >> MAY) then I guess you are right. OTOH, maybe not if there is just a note >> about it, explaining that it it technically a non-conforming usage, and >> discussing the pros/cons of doing so. >> >> Thanks, >> Paul >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > From nobody Fri Apr 15 14:19:30 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEAB12D678; Fri, 15 Apr 2016 14:19:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160415211927.17554.51872.idtracker@ietfa.amsl.com> Date: Fri, 15 Apr 2016 14:19:27 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-mux-exclusive-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 21:19:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP Author : Christer Holmberg Filename : draft-ietf-mmusic-mux-exclusive-04.txt Pages : 11 Date : 2016-04-15 Abstract: This document defines a new SDP media-level attribute, 'rtcp-mux- only', that can be used by an endpoint to indicate exclusive support of RTP/RTCP multiplexing. The document also updates RFC 5761, by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-mux-exclusive-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-mux-exclusive-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 15 14:21:10 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7E112D5EF; Fri, 15 Apr 2016 14:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGHiIF5KUrzo; Fri, 15 Apr 2016 14:21:07 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918F812D577; Fri, 15 Apr 2016 14:21:06 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-ae-57115b40d18e Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 67.14.12926.04B51175; Fri, 15 Apr 2016 23:21:04 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Fri, 15 Apr 2016 23:21:03 +0200 From: Christer Holmberg To: mmusic Thread-Topic: Draft new version: draft-ietf-mmusic-mux-exclusive-04 Thread-Index: AdGXXJMP+yDz1ZzQR9WCJ2Oun+jDEg== Date: Fri, 15 Apr 2016 21:21:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F39650@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37F39650ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbHdQ9chWjDcYO52Q4vzO9czWUxd/pjF gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZuy/+Yy+YLFHRubWPsYFxk2gXIyeHhICJxO697UwQ tpjEhXvr2boYuTiEBI4wStw/9IEFwlnMKDFt4gMgh4ODTcBCovufNkiDiICMxN5Nm5lBbGYB U4mHr9YwgtjCAnYSV77vYYGocZb49ukQM4StJ/Fg50WwZSwCqhJv/v8Gq+cV8JX41HKIFcRm BDri+6k1TBAzxSVuPZkPdZyAxJI955khbFGJl4//sULYShKNS56wQtTnS0z+eYAZYqagxMmZ T1gmMArPQjJqFpKyWUjKIOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypG0eLU4qTcdCNj vdSizOTi4vw8vbzUkk2MwKg5uOW36g7Gy28cDzEKcDAq8fAmNAuEC7EmlhVX5h5ilOBgVhLh tYgUDBfiTUmsrEotyo8vKs1JLT7EKM3BoiTOmx35L0xIID2xJDU7NbUgtQgmy8TBKdXA6PtB SHtSffW/BntvnRLVgLmF/74Gntlvsdd+u9Psrq3p/3s/G3BsLTbUU4x+xna4Zm9aI3d4slJW 48N+YZnFDZfcJjsftntitn1r1b8ibfNZagHaRRsNjZkqEpOXflH/oHd0f8M+0Tfx06M/GjYG J94wShNzqmb78362P0fC5dkBMYG9b28osRRnJBpqMRcVJwIAeuCehZYCAAA= Archived-At: Cc: "mmusic-chairs@ietf.org" Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-04 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 21:21:08 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37F39650ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version (-04) of draft-ietf-mmusic-mux-exclusive. The name of the new attribute has now been changed to 'rtcp-mux-only', as s= uggested by Roman. In addition, the draft now updates two paragraphs on RFC 5761. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37F39650ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted a new version (-04) of draft-ie= tf-mmusic-mux-exclusive.

 

The name of the new attribute has now been changed t= o ‘rtcp-mux-only’, as suggested by Roman.

 

In addition, the draft now updates two paragraphs on= RFC 5761.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37F39650ESESSMB209erics_-- From nobody Fri Apr 15 14:25:47 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C77B812DA6A; Fri, 15 Apr 2016 14:25:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160415212545.17459.29365.idtracker@ietfa.amsl.com> Date: Fri, 15 Apr 2016 14:25:45 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-29.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 21:25:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-29.txt Pages : 53 Date : 2016-04-15 Abstract: This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single address:port combination (BUNDLE address) for receiving media, referred to as bundled media, specified by multiple SDP media descriptions ("m=" lines). To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. There are multiple ways to correlate the bundled RTP packets with the appropriate media descriptions. This specification defines a new Real-time Transport Protocol (RTP) source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/ RTCP packets with a specific media description. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-29 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-29 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 15 14:27:38 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C4C12DEBA; Fri, 15 Apr 2016 14:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X17edXGVbYTp; Fri, 15 Apr 2016 14:27:35 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 867D112DCAA; Fri, 15 Apr 2016 14:27:34 -0700 (PDT) X-AuditID: c1b4fb2d-f79006d000006928-a5-57115cc45c2e Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BE.1F.26920.4CC51175; Fri, 15 Apr 2016 23:27:32 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0248.002; Fri, 15 Apr 2016 23:27:17 +0200 From: Christer Holmberg To: mmusic Thread-Topic: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-29 Thread-Index: AdGXXXV4nXV0SzIJSxKWdTMOUnfnzg== Date: Fri, 15 Apr 2016 21:27:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F396BC@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37F396BCESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbFdUfdIjGC4wcqFNhbnd65nspi6/DGL A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyJqydw16wQbTi06FbTA2Mv4S6GDk4JARMJPYfCe9i 5AQyxSQu3FvP1sXIxSEkcIRRYvWUPmYIZzGjxNONW9lAGtgELCS6/2mDNIgIyEjs3bSZGcRm FjCVePhqDSOILSzgLvG3/QAzSLmIgI/Ex/5AiHI9iTffXjOB2CwCqhL77/wHK+EV8JX4dcgb JMwIdML3U2uYICaKS9x6Mp8J4jQBiSV7zjND2KISLx//Y4WwlSQalzxhhajPl+hqO8sOYvMK CEqcnPmEZQKj8Cwko2YhKZuFpAwiriOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYhQtTi0u zk03MtZLLcpMLi7Oz9PLSy3ZxAiMl4NbfuvuYFz92vEQowAHoxIPb0KzQLgQa2JZcWXuIUYJ DmYlEV6LSMFwId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rw5kf/ChATSE0tSs1NTC1KLYLJMHJxS DYxs99JZpmZb71XqOxiS0H7HXfCcmv3aBhv+n/lrxIHuvFqe+SJFe41iSTU/N7+SqveCFTnz cpxc7tatOpTDv/anWbOBQ7GJAP9Bp+iZ9ktkmGrfnhLLTekWZzKPuvQ6Xjl/n4aBZKnUrxfG /69OVTr4eHP9o1a59lXPPtmm6O9Wl6zpfielxFKckWioxVxUnAgAi5oNJ5MCAAA= Archived-At: Cc: "mmusic-chairs@ietf.org" Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-29 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 21:27:36 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37F396BCESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version (-29) of BUNDLE. The changes are in order to a= lign with the latest version of draft-mux-exclusive. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37F396BCESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted a new version (-29) of BUNDLE. = The changes are in order to align with the latest version of draft-mux-excl= usive.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37F396BCESESSMB209erics_-- From nobody Mon Apr 18 08:00:02 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5454612D8FA for ; Mon, 18 Apr 2016 08:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 nT_ELRPdxCYq for ; Mon, 18 Apr 2016 07:59:58 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674D312D7E5 for ; Mon, 18 Apr 2016 07:59:58 -0700 (PDT) Received: by mail-ig0-x233.google.com with SMTP id gy3so74956754igb.0 for ; Mon, 18 Apr 2016 07:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=/2X85TYujLShjb8N9f4zk7/Wakys+Nwa6CAx2DBtLLY=; b=zxFIcrIyBwDTqUO8NSUocuMoS0Vf/IH3vUy6E/+ozeJ6MsxjK7t3PkyyKvvrjVZinC jE+pL97SnQ0fpGs46VMsSo5dQfPMeZvZUpeTqbNBZHvlnQWEHjJetLbOmXBSvQPZd9Wm MtC9hON9/IZgL22/ylvRX1/F3rmQMsiOU/FvFBxctbBKgyvOAuKb6TnSA4zaHSsU4K7p YZ7cNirOrsW9pqLUQkNpuDTT+0p37Z6fCWyukH9nKKKMTnOpMQFJL3mkBMLNehqDPQvw G54TYeYBCCymXIldPOWJvivHVZdw+tF+LS4Lm5to0E65MpL2qqjSL+wfqw1JCwF7qccG zAcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/2X85TYujLShjb8N9f4zk7/Wakys+Nwa6CAx2DBtLLY=; b=BJYRl3bioLXGqwITNGGHt7V5pQShcdD3we4gRLIiHoWnXDW3fXVrjKVSoFNWhLrW6i kRkudfGnNOOp1CJF/fVodomiRSRe38Fuk8Ehd2mwQHdr15NzoPXXNQ0vS8+SqhOETqpE t2jo0mp1YXo7RWdaVHD3sFoaoTdu695C/7pYu6SonASsjNQkGRsfcd0q6yc9ykWj24O+ UMZOhFqlNmgIWc2RLUEA29tvbYsbHwayhhmSvig2zg/bUAPpcIP9ZHplfJVMFC9dxaOD L+DfVQu4BX7+8DlWgyxHGJTmfjiSupsuubqIICHLsJHdFrc1Ii7Vs0ePKxShgBo2drox a13A== X-Gm-Message-State: AOPr4FWUdd1aqUgK5ygQMozuET+vhIfSGbKtezTjYNs554gPtxx/XMuQVs5CGs8Lme05AQ== X-Received: by 10.50.118.225 with SMTP id kp1mr20644844igb.9.1460991597612; Mon, 18 Apr 2016 07:59:57 -0700 (PDT) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com. [209.85.223.169]) by smtp.gmail.com with ESMTPSA id ke5sm3660185igb.17.2016.04.18.07.59.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Apr 2016 07:59:56 -0700 (PDT) Received: by mail-io0-f169.google.com with SMTP id g185so197162200ioa.2; Mon, 18 Apr 2016 07:59:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.160.141 with SMTP id j135mr42233717ioe.171.1460991596536; Mon, 18 Apr 2016 07:59:56 -0700 (PDT) Received: by 10.36.144.69 with HTTP; Mon, 18 Apr 2016 07:59:56 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Apr 2016 10:59:56 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1140a2b621b1a00530c39d18 Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 15:00:00 -0000 --001a1140a2b621b1a00530c39d18 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla wrote: > I wanted to call your attention to a draft I just published with a > possibly stupid > idea. > > https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 > > A nontrivial fraction of call setup time in WebRTC is the DTLS handshake. > This document describes how to piggyback the first few handshake messages > in the SDP offer/answer exchange, thus reducing latency. > > Comments welcome. > > One other issue I thought off was that with DTLS SDP either offerer or answerer can start a new DTLS association. When answerer starts a new session it will have exactly the same problems as forking, since this will create multiple DTLS sessions with the same client random. This can be solved with some sort of fallback mechanism to either regular DTLS setup or to sending a ClientHello in the answer. Regards, _____________ Roman Shpount --001a1140a2b621b1a00530c39d18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla <ekr@rtfm.com>= wrote:
I wanted to call your attention to a draft I just published w= ith a possibly stupid
idea.

https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00

A nontrivial fraction of call setup time in WebRTC is= the DTLS handshake.
This document describes how to piggyback the= first few handshake messages
in the SDP offer/answer exchange, t= hus reducing latency.

Comments welcome.
=

One other issue I thought = off was that with DTLS SDP either offerer or answerer can start a new DTLS = association. When answerer starts a new session it will have exactly the sa= me problems as forking, since this will create multiple DTLS sessions with = the same client random. This can be solved with some sort of fallback mecha= nism to either regular DTLS setup or to sending a ClientHello in the answer= .

Regards,
_____________
Roman Shpount
=C2=A0
--001a1140a2b621b1a00530c39d18-- From nobody Tue Apr 19 23:00:12 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE5212DC88; Tue, 19 Apr 2016 23:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 P-rrSg43mCzY; Tue, 19 Apr 2016 23:00:06 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F21612E5C9; Tue, 19 Apr 2016 23:00:03 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id t10so42897386ywa.0; Tue, 19 Apr 2016 23:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=3FOE97VhvoUnABd8k0kzOotgW+ILRbbtHvj2IixiXBk=; b=B84GOFJ0/oMM2Bbf1m2ITga7wSy4lxkqN5KlrmrrAy1g7oAhC99Czq6lBpufLA82KP ZY/UeJ97XTn7LjRVZYEsf/R77Ew220GLpIR9m/8TQjQAcy8tPZEshnmCT3f/D3E+0573 d8bQ0XRlMfgpBKKAQ6nrox7ZFIgmr73Z5muqGYoEN3FmymcL3BtUIJz5Y6AZ0FONA1Vp zfztMndNJK6OpCu2QAxeJk2jE1OBMOlviqN0ZXcWvD78B+QeWMkQB8IminUG36Nn8OtB uXywkI5zFeCTdf6DIsu5vgfaos2N6Ka/oZkMuzDlRow8DkkTvPZtBwmqU3O4hh8LAP5y Rn/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=3FOE97VhvoUnABd8k0kzOotgW+ILRbbtHvj2IixiXBk=; b=YH+7/J8nmhbIu2qfIBpchb2fZ1jGX1Okft+F4uDKIBE1vr9NBHCQj02dgk0ULRYTKM 9pgGxXNbohJ9hcvvTN29MCtdAS29Owzt8THDT/kNpy6WkWgXHMkGxXxedESJXE+4G1ct YyFfx3IlEopuzhuJnnUyY16B2nLwUui7gYEYCQW5YxXu9FLtiKmiAVtBN5eXyHL1Ovbe wI9iz6mJqtNnvhffovXD5yCNr/iNZOpNNRyw+buPBAyegKlFqZSamf2zuBxFglzb78xH 1z3ajRwe+vBGiGWZBFs4l8rD1xd3nxvRmIKv1oID52n9b2Q8i/VJI8o8N8u+zzS5F0Pb Xujg== X-Gm-Message-State: AOPr4FWThfzhul8/lmHAIYpp72LExaxsGJZmCl4kZFg9QU6F0gi69e/pxFa36OynqBFgI5bIQ9jWEIplFwPSyg== MIME-Version: 1.0 X-Received: by 10.37.209.20 with SMTP id i20mr4250728ybg.15.1461132002462; Tue, 19 Apr 2016 23:00:02 -0700 (PDT) Received: by 10.129.54.15 with HTTP; Tue, 19 Apr 2016 23:00:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Apr 2016 23:00:02 -0700 Message-ID: From: Suhas Nandakumar To: Ben Campbell Content-Type: multipart/alternative; boundary=94eb2c06eb86fa15bf0530e44d3c Archived-At: Cc: mmusic WG , draft-ietf-mmusic-sdp-mux-attributes.all@ietf.org Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sdp-mux-attributes-12 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 20 Apr 2016 06:00:11 -0000 --94eb2c06eb86fa15bf0530e44d3c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Ben Sorry for the delay in responding. Many thanks for the detailed review. Please find my responses inline (marked by [Suhas]). Cheers Suhas On Fri, Feb 19, 2016 at 2:28 PM, Ben Campbell wrote: > Hi, > > Here is my AD evaluation of draft-ietf-mmusic-sdp-mux-attributes-12. I > would like at least the substantive > section to be discussed before going to IETF last call. > > Thanks! > > Ben. > > ---------- > > # Substantive # > > - This is very long and detailed. Are the authors and chairs comfortable > that all sections have had sufficient review? > > -4.0: It would be helpful to add a paragraph describing how these semanti= c > groupings map to the categories. > [Suhas] The semantic groupings were added as a informal reference and they don't really interact with the categories as such. Does the following rephrasing work *"Attributes in an SDP session description can be defined at the **session-level or media-level or source-level. Informally, there are various semantic grouping for these attributes. One such grouping could be as noted below:* * o Attributes related to media content such as media type, encoding schemes, payload types. o Attributes specifying media transport characteristics like RTP/RTP Control Protocol (RTCP) port numbers, network addresses, QOS. o Metadata description attributes capturing session timing and origin information. o Attributes establishing relationships between media descriptions such as grouping framework [RFC5888 ]The proposed framework defines categories for the SDP attributes under multiplexing and assigns each SDP attribute to an appropriate multiplexing category.* *Since the multiplexing categories defined in this specification are independent of any informal semantic grouping of the SDP attributes, the categorizations assigned against each attribute MUST be considered as normative assignments under multiplexing. "* > -4.2: I recommend choosing a category name that is not a 2119 keyword. > Maybe something like "not mux-able" or "unsafe"? > [Suhas] Initially that category was called "BAD" as in https://datatracker.ietf.org/doc/draft-nandakumar-mmusic-sdp-mux-attributes= /01/ However we ended upon NOT RECOMMENDED since =E2=80=9CBAD=E2=80=9D was a bad= choice :-) Either of the following options seems fine to me 1. NOT-RECOMMENDED [ we use hyphen separated multi word format in other category names] 2. UNSAFE > > -4.3: Please don't use a 2119 keyword as part of the definition > of a category. This creates sort of a circular dependency; that is > attributes are in this category because they MUST be identical; but they > MUST be identical because they are in this category. I suggest describing > the category descriptively, and adding a separate sentence to say > "Attributes > in the IDENTICAL category MUST be identical across all media descriptions= ." > [Suhas]. I have removed the usage of word identical from the definition as below. Please let me know if this works. Category: IDENTICAL Attributes and their associated values (if present) in the IDENTICAL category MUST be repeated across all the media descriptions under multiplexing. > > -4.6: > >"This in turn MAY place constraints on what constitutes a valid > configuration from > a multiplexing point of view, e.g. because some attributes MUST be > IDENTICAL (see Section 14 for further details)." > > It seems like it would make sense to state that last sentence > more strongly. Does it make sense to say something along the lines > of "inherited attributes MUST be coherent."? > [Suhas]. Works as suggested. > > -4.9: "For the purposes of implementations it is > advised to consider "NOT RECOMMENDED" as the category when > multiplexing these attributes." > > So why not have them in the NOT RECOMMENDED category, with > an explanation that they have not been sufficiently analyzed? > Or if you want to keep a separate category, you can say something > like :"Attributes in the TBD category SHOULD NOT be multiplexed." > > [Suhas] We would want a separate category to differentiate between the actual NOT-RECOMMENDED ones and the ones which has not yet been Analysed. I am happy to consider the suggestion "Attributes in the TBD category SHOULD NOT be multiplexed." > -5.8 and 5.9: > The last paragraph of 5.8 seems redundant with section 5.9. > > -5.8, last paragraph: > > "Hence multiplexing MUST NOT be performed even in this > alternate scenario." seems to contradict the category selection of > "NOT RECOMMENDED" (but see previous comment about not using 2119 > keywords in a category title.) > > [Suhas] The idea here is to not perform multiplexing and hence the category of NOT RECOMMENDED assigned. I can update this once we finalize on the right naming for "NOT RECOMMENDED" > -5.14 > Do you really expect to see such an "early mechanism" be > multiplexed? > > [Suhas] In the context of WebRTC, implementations today do use use both a=3Drtcp attribute and BUNDLE framework for multiplexing media descriptions. > -5.24, last paragraph: "it is recommended to consult the > document defining the attribute." > > I assume one should _always_ refer to the specification of > an SDP attribute before trying to mux it. But that doc is > not going to explain muxing issues, is it? > > [Suhas] Since cparmin/cparmax can define numerical values/ranges for any of b=3D or a=3D attributes (identified via cpar), there is no easy = way to assign a multiplexing category unless one knows what cpar is being used and the assignned numerical values to each of cparmin/cparmax mean. Thus the category SPECIAL has been assigned as a recommendation for the implementor to consult the spec that defines a particular usage of cpar, cparmin and cparmax combination to really see what=E2=80=99s going on. This is very similar to extmap or RTCP Application feedback message type How about following rephrasing *"The attributes (a=3Dcparmin and a=3Dcparmax) define minimum and maximum numerical values associated with the attributes described in a=3Dcpar. Sinc= e a cpar attribute can either define* *=E2=80=9Cb=3D=E2=80=9D attribute or any =E2=80=9Ca=3D=E2=80=9D attribute, = the multiplexing category * *depends on actual attribute being encapsulated and the implications of the numerical values assigned. Hence it is recommended to consult the specification defining the the attributes (cparmin/cparmax) to further analyze their behavior under multiplexing."* > -5.26: > -"Support of this extension is OPTIONAL." > Please don't use 2119 keywords to describe existing requirements > from other docs, unless in direct quotes. > > [Suhas] This sentence is taken directly from RFC6714. ( https://tools.ietf.org/html/rfc6714) > -Note: As stated, this is untrue. MSRP has the built in ability > to share multiple sessions across the same transport connection. > But I think your point is that there is no specification about > how to demux MSRP from among _other_ protocols. > > The MUST in the last sentence does not seem appropriate. You can't > really create a 2119 level requirement for people to do work in > the future. I suggest s/"MUST be revisited"/"could be revisited" > > -5.28: Same comments as for 5.26. > > [Suhas] Sure, will change as suggested for both 5.26 & 5.28 . > - 5.39: > I=E2=80=99m not a zrtp expert, but it seems like it might > be more complicated than this. Section 8 of 6189 says > =E2=80=9CThe a=3Dzrtp-hash attribute can only be included in the > SDP at the media level since Hello messages sent in > different media streams will have unique hashes.=E2=80=9D > I wonder if this shouldn't be =E2=80=9Cidentical=E2=80=9D? > > [Suhas] The category TRANSPORT is the appropriate assignment. This spec assigns category for these attributes over the multiplexed transport. So, if we have 3 m=3D lines each with one zrtp-hash and all bundled. The zrtp-hash selected must correspond to the m=3Dline that is selected for BUNDLE once the O/A negotiation completes. Thus the category TRANSPORT. > -5.40: > I'm surprised that the comedia attributes are not "transport" > > [Suhas] . Agree. Will change as suggested. > -5.42: > See previous comments about MUST level requirements for > doing future work. (I think this recurs for some or all TBD > sections.) > [Suhas] . Agree. Will change as suggested. > > -5.45: > 6193 is an ISE stream RFC. Does anyone actually use > in a context where muxing matters? > [Suhas] . I doubt it. Do you recommend as NOT-RECOMMENDED instead. > - 5.57: > See comments from 5.26 > [Suhas] Sure , will update accordingly. > > -15.1: > - Is there no need for a spec for any newly registered categories? > - 2nd to last paragraph: "This seems vague for a MUST. Do you expect > the registration of a new category to change the categories > already assigned to existing SDP parameters? Is it possible > that a new category only applies to some new SDP parameters?" > [Suhas] The following 2 paragraphs are supposed to mean that new multiplexing categories require new registrations via a spec and applicability of the new category to new SDP attributes and possibly existing SDP attributes ( if the new category makes more sense). What would be a better framing to capture the intent ? "*Further entries can be registered on a first-come first-serve basis. Each registration needs to indicate the multiplexing category value to be added to the "Multiplexing Categories" subregistry as defined in this section.* *Such a registration MUST also indicate the applicability of the newly defined multiplexing category value to various subregistries defined at "Session Description Protocol (SDP) Parameters".* > - Last paragraph: 4566 procedures apply to what? The text just said > new categories are first-come-first server. I don=E2=80=99t think > 4566 set policies for how to change mux categories. > [Suhas] Agreed. I prefer removing this line altogether. Please let me know > > -15.2.1: > How do you expect the table to look after adding this RFC to the > references? Will this RFC be added to the entries in the MUX > column? > [Suhas] The plan was to add the reference to this RFC in the "Reference Column" > > -16: > - Do the assumptions for things like =E2=80=9Cfingerprint=E2=80=9D and = the zrtp > hash not have security considerations since they force multiple > media streams to share the same security associations? > (Maybe that is covered by bundle?) > [Suhas] This should be covered in bundle spec. - 2nd paragraph: There are more than one srtp keying mechanism=E2=80=94is > this assumed true for all of them? > > [Suhas] SDES, DTLS doesn't violate RFC3711 and thus no two-time pad. These are the currently defined mechanisms and thus i believe the statement holds true. > > > # Editorial # > > - xml2rfc reports some outdated references. Are those intentional? > > [Suhas] not intentional. will update them > - The abstract is more detailed than needed. The point is to describe the > purpose of the draft. The second paragraph pretty much accomplishes that. > > [Suhas] How do this rephrase look =E2=80=9CThe purpose of this specification is to provide a framework for an= alyzing the multiplexing characteristics of SDP attributes when SDP is used to negotiate the usage of single 5-tuple for sending and receiving media associated with multiple media descriptions,. This specification also categorizes the existing SDP attributes based on the framework described herein.=E2=80=9D > - Please include table numbers. > [Suhas] Sure, will do. > > - 1: > - First paragraph: > s/"This would for e.g."/This would, for example," > [Suhas] Will change > s/"has made necessary to understand"/"has made it necessary to > understand" > [Suhas] Will change > - 2nd paragraph: > "Generic future-proof framework" - This seems excessive--can we just ca= ll > it a framework? > [Suhas] Sure > > -3: > - 1st paragraph, first sentence: Convoluted sentence. Can it be > simplified? > > -4: > - first and second bullet example lists are each missing "and". > > -4.2, first paragraph: Sentence fragment. (same for several category > descriptions.) > > -4.4, first sentence: Spurious comma. > [Suhas] . Will fix these as suggested > > -4.6, last paragraph: "In the above example, the category IDENTICAL is > inherited for the cpar encapsulated rtcp-mux attribute." > > "For" doesn't seem like the right proposition. Is the category > inherited "from" the cpar? "by" the cpar? > [Suhas] True . I will change it to "by" the cpar. > > -5 and subsections: Is there any method to the ordering? They aren't > in RFC order. It might make sense to group by the nature of the > attributes, but if that is the case here it's not explained. > > [Suhas] These are not ordered as of today. I can order the 5.X subsections by RFC order, if needed. > -5.4, note: "... due to inability in meeting > the right resource reservations requested." > > I can't parse that clause. Does it mean "inability to meet the > resource reservation request"? "Inability to determine the correct > resource reservation request"? > [Suhas] It's the former. Will correct it. > > -5.8, last paragraph: > - "None of this is standardized yet and it wouldn=E2=80=99t work > as explained. " > > Does this mean that it has been explained why it wouldn't work? Or do you mean the way it is explained wouldn't work? > [Suhas] . It means that it doesn't work for the reasons explained in this paragraph. > > -5.9: > -s/"[RFC6773] document specifies"/"[RFC6773] specifies" > - last paragraph: s/"can or cannot"/"may or may not" > [Suhas] . Sure will update > > -5.13, table: > "Specific RTP extension document MUST be referred" > > [Suhas] The idea was to mean that , one should refer to the specification that defines a specific RTP extension in order to understand the multiplexing behavior. Would the following rephrasing help instead "Refer to the document defining specific RTP Extension" > I don=E2=80=99t understand what that means. If you mean to > say =E2=80=9Crefer to specific document=E2=80=9D, that shouldn=E2=80= =99t use MUST. > > -5.22, table: "document needs to be referred" (several repetitions) > I'm not sure what this means. Should it say "Refer to the > specific document"? > > Similarly as above, would this reprhasing help "Refer to the document defining specific FEC Scheme > -5.27, table: If the "MUST be globally unique" requirement refers to > and existing requirment from 4583, please avoid 2119 language. > [Suhas] Sure , will update > > -5.55: "... to be referred ..." > I suggest "Refer to...." > [Suhas] Will do so > > -6.3: "not clearly defined offer/answer usage" > I'm not sure what is meant here. (Also, why is this not TBD or NOT > RECOMMENDED?) > [Suhas] Since RFC3890 b=3DTIAS is not defined keeping O/A in mind, either t= he BUNDLE spec or this spec cannot define its mux behavior. This is due to applicability of these specs under SD{ O/A usages alone. I can rephrase the above as "not defined under SDP Offer/Answer usage" > > -14.2.1, last paragraph: > Do I understand this correctly to mean that the answerer can > always fall back to a =E2=80=9Ccommon-to-all=E2=80=9D config even if th= e offerer > offered additional independent configs? > [Suhas]. That's a possibility if the answerer isn't able to use any of the additional configurations offered > > -14.3: > s/"...extends capability..."/"...extends the capability..." > [Suhas] Will update > > -14.3.1: "which MUST be followed here as well." > If bundle-negotiation already requires identical pt values, > isn=E2=80=99t this MUST redundant to that one? > > [Suhas] . agreed and will reword > 14.3.2: > I suspect that first MAY is a statement of fact, not a new > requirement. > [Suhas] . agreed and will change to may instead of MAY > > -15, paragraph starting with "The IANA is requested to...": > This sentence seems to belong with the next paragraph. > [Suhas] . Sure will move it > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --94eb2c06eb86fa15bf0530e44d3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Ben

=C2=A0Sorry for the delay in = responding. Many thanks for the detailed review.

= =C2=A0Please find my responses inline (marked by [Suhas]).

Cheers
Suhas

On Fri, Feb 19, 2016 at 2:28 PM, Ben Campbell <ben@nostr= um.com> wrote:
Hi,

Here is my AD evaluation of draft-ietf-mmusic-sdp-mux-attributes-12. I woul= d like at least the substantive
section to be discussed before going to IETF last call.

Thanks!

Ben.

----------

# Substantive #

- This is very long and detailed. Are the authors and chairs comfortable that all sections have had sufficient review?

-4.0: It would be helpful to add a paragraph describing how these semantic<= br> groupings map to the categories.

[Suhas] The semantic grouping= s were added as a informal reference and they don't really interact wit= h the categories as such.=C2=A0

Does the following rephrasing work=C2=A0

"Attributes in an SDP session description can be de= fined at the session-level or =C2=A0media-level or =C2=A0source-level. Informally, there are various se= mantic grouping for these attributes. One such grouping could be as noted below:

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= i> =C2=A0=C2=A0o =C2= =A0Attributes related to media content such as media type, encoding<= span style=3D"font-size:13.3333px;color:rgb(0,0,255);vertical-align:baselin= e;white-space:pre-wrap;background-color:transparent">
= =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0schemes, payload types.
 =C2=A0=C2=A0o =C2=A0Attributes specifying media tran= sport characteristics like RTP/RTP
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Control Protocol (RTCP)= port numbers, network addresses, QOS.
 =C2=A0=C2=A0o =C2=A0Metadata description attribut= es capturing session timing and
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0origin information.=
=C2=A0=C2=A0o =C2= =A0Attributes establishing relationships between media descriptions<= span style=3D"font-size:13.3333px;color:rgb(0,0,255);vertical-align:baselin= e;white-space:pre-wrap;background-color:transparent">
= =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0such as grouping framework [RFC5888<= span style=3D"font-size:13.3333px;color:rgb(0,0,255);vertical-align:baselin= e;white-space:pre-wrap;background-color:transparent">]

The proposed framework defines = categories for the SD= P attributes under multiplexing and assigns each SDP attribute to an appropriate multiplexing c= ategory.


Since the multiplexing categories defined in this specifica= tion are independent= of any informal semantic grouping of the SDP attributes, the categorizations assigned against each attribute =C2=A0= MUST be considered as normative assignments under multiplexing. "

=C2=A0


-4.2: I recommend choosing a category name that is not a 2119 keyword.
=C2=A0 Maybe something like "not mux-able" or "unsafe"?=

[Suhas]

Initially= that category was called "BAD" as in

https://datatracker.ietf.org/doc/draft-n= andakumar-mmusic-sdp-mux-attributes/01/

However we ended upon NOT RECOMMENDED since =E2=80=9CBAD=E2= =80=9D was a bad choice :-)

Eit= her of the following options seems fine to me

  1. NOT-RECOMMENDED [ we use hyphen separated multi word for= mat in other category names]

  2. UNSAFE

=C2=A0

-4.3: Please don't use a 2119 keyword as part of the definition
of a category. This creates sort of a circular dependency; that is
attributes are in this category because they MUST be identical; but they MUST be identical because they are in this category. I suggest describing the category descriptively, and adding a separate sentence to say "Att= ributes
in the IDENTICAL category MUST be identical across all media descriptions.&= quot;


[Suhas]. I have removed the usa= ge of word identical from the definition as below. Please let me know if th= is works.


Category: IDENTICAL

Attributes= =C2=A0and their associated values (if present) in the IDENTICAL category M= UST be repeated across all the media descriptions under multiplexing.



=C2=A0

-4.6:
=C2=A0>"This in turn MAY place constraints on what constitutes a va= lid
=C2=A0 =C2=A0configuration from
=C2=A0 =C2=A0a multiplexing point of view, e.g. because some attributes MUS= T be
=C2=A0 =C2=A0IDENTICAL (see Section 14 for further details)."

=C2=A0 =C2=A0It seems like it would make sense to state that last sentence<= br> =C2=A0 =C2=A0more strongly. Does it make sense to say something along the l= ines
=C2=A0 =C2=A0of "inherited attributes MUST be coherent."?

[Suhas]. Works as sugg= ested.
=C2=A0

-4.9: "For the purposes of implementations it is
=C2=A0 =C2=A0advised to consider "NOT RECOMMENDED" as the categor= y when
=C2=A0 =C2=A0multiplexing these attributes."

=C2=A0 =C2=A0So why not have them in the NOT RECOMMENDED category, with
=C2=A0 =C2=A0an explanation that they have not been sufficiently analyzed?<= br> =C2=A0 =C2=A0Or if you want to keep a separate category, you can say someth= ing
=C2=A0 =C2=A0like :"Attributes in the TBD category SHOULD NOT be multi= plexed."


[Suhas] We would want a separate category to differ= entiate between the

actual NOT-RECOMMENDED ones and the ones whi= ch has not yet been

Analysed.


I am happy to consider the suggestion "Attributes in the = TBD category SHOULD NOT be multiplexed."

=
=
=C2=A0
-5.8 and 5.9:
=C2=A0 =C2=A0 The last paragraph of 5.8 seems redundant with section 5.9.
-5.8, last paragraph:

=C2=A0 =C2=A0 "Hence multiplexing MUST NOT be performed even in this =C2=A0 =C2=A0 alternate scenario." seems to contradict the category se= lection of
=C2=A0 =C2=A0 "NOT RECOMMENDED" (but see previous comment about n= ot using 2119
=C2=A0 =C2=A0 keywords in a category title.)


[Suhas] The idea here is to not perform multiplexing and h= ence the category of NOT RECOMMENDED assigned. I can update this once we fi= nalize on the right naming for "NOT RECOMMENDED"

=C2=A0
-5.14
=C2=A0 Do you really expect to see such an "early mechanism" be =C2=A0 multiplexed?


[Suhas]

In the context of WebRTC, implementations today do use use both a=3Drtcp attribute and BUNDLE framework for multiplexing media descriptions.


=C2=A0
= -5.24, last paragraph: "it is recommended to consult the
=C2=A0 document defining the attribute."

=C2=A0 I assume one should _always_ refer to the specification of
=C2=A0 an SDP attribute before trying to mux it. But that doc is
=C2=A0 not going to explain muxing issues, is it?


<= /div>

[Su= has]

Since cparmin/cparmax can = define numerical values/ranges

= for any of b=3D or a=3D attributes (identified via cpar), there is no easy = way to assign a multiplexing category unl= ess one knows what cpar is being

each of cparmin/cparmax mean. Thus the category SPECIAL has been assigned as a recommendation for the implemento= r to consult the spec that defines a part= icular usage of cpar, cparmin and cparmax combination to really see what=E2=80=99s going on.


This is very similar to extmap or RTCP Application= feedback message type


How = about following rephrasing

"The attributes (a=3Dcparmin and a=3Dcparmax) define mini= mum and maximum numerical values associated with the attributes described i= n a=3Dcpar. Since a cpar attribute can either define

=E2=80=9Cb=3D=E2=80=9D attribute or any =E2= =80=9Ca=3D=E2=80=9D attribute, =C2=A0the multiplexing category <= /p>

depends on actual attribute being e= ncapsulated and the implications of the numerical values assigned. Hence it is recommended to consult the specification defining the the attributes (cparmin/= cparmax) to further analyze their behav= ior under multiplexing."


=C2=A0
-5.26:
=C2=A0 -"Support of this extension is OPTIONAL."
=C2=A0 Please don't use 2119 keywords to describe existing requirements=
=C2=A0 from other docs, unless in direct quotes.



[Suhas] This sentence is taken direc= tly from RFC6714. (https://= tools.ietf.org/html/rfc6714)


=C2=A0
=C2=A0 -Note: As stated, this is untrue. MSRP has the built in ability
=C2=A0 to share multiple sessions across the same transport connection.
=C2=A0 But I think your point is that there is no specification about
=C2=A0 how to demux MSRP from among _other_ protocols.

=C2=A0 The MUST in the last sentence does not seem appropriate. You can'= ;t
=C2=A0 really create a 2119 level requirement for people to do work in
=C2=A0 the future. I suggest s/"MUST be revisited"/"could be= revisited"

-5.28: Same comments as for 5.26.


[Suhas] Sure, will change as suggested for bot= h 5.26 & 5.28 .


=C2=A0<= /div>
- 5.39:
=C2=A0 I=E2=80=99m not a zrtp expert, but it seems like it might
=C2=A0 be more complicated than this. Section 8 of 6189 says
=C2=A0 =E2=80=9CThe a=3Dzrtp-hash attribute=C2=A0 can only be included in t= he
=C2=A0 SDP at the media level since Hello messages sent in
=C2=A0 different media streams will have unique hashes.=E2=80=9D
=C2=A0 I wonder if this shouldn't be =E2=80=9Cidentical=E2=80=9D?


[Suhas] The category TRANSPORT is the appropriate a= ssignment. This spec assigns category for= these attributes over the multiplexed transport.

So, if we hav= e 3 m=3D lines each with one zrtp-hash and all bundled.

<= p style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt">The zrtp-hash select= ed must correspond to the m=3Dline that is selected for BUNDLE once the O/A= negotiation completes. Thus the catego= ry TRANSPORT.


=C2=A0
-5.40:
=C2=A0 I'm surprised that the comedia attributes are not "transpor= t"


[Suhas] . Agre= e. Will change as suggested.
=C2=A0
-5.42:
=C2=A0 See previous comments about MUST level requirements for
=C2=A0 doing future work. (I think this recurs for some or all TBD
=C2=A0 sections.)

[Suhas] . Agree. Will change as suggested.
<= font color=3D"#0000ff">
=C2=A0

-5.45:
=C2=A0 6193 is an ISE stream RFC. Does anyone actually use
=C2=A0 in a context where muxing matters?

[Suhas] .=C2=A0I doubt it. Do you recommend a= s NOT-RECOMMENDED instead.


- 5.57:
=C2=A0 See comments from 5.26

[Suhas] Sure , will up= date accordingly.

=C2=A0

-15.1:
=C2=A0 - Is there no need for a spec for any newly registered categories? =C2=A0 - 2nd to last paragraph: "This seems vague for a MUST. Do you e= xpect
=C2=A0 =C2=A0 the registration of a new category to change the categories =C2=A0 =C2=A0 already assigned to existing SDP parameters? Is it possible =C2=A0 =C2=A0 that a new category only applies to some new SDP parameters?&= quot;

[Suhas] T= he following 2 paragraphs are supposed to mean that new multiplexing catego= ries require new registrations via a spec and applicability of the new cate= gory to new SDP attributes and possibly existing SDP attributes ( if the ne= w category makes more sense). What would be a better framing to capture the= intent ?

"Further entries can be r= egistered on a first-come first-serve basis. Each registration needs to ind= icate the multiplexing category value to be added to the "Multiplexing= Categories" subregistry as defined in this section.

Such a registration MUST also indicate the applicability of= the newly defined multiplexing category value to various subregistries def= ined at "Session Description Protocol (SDP) Parameters".

=C2=A0
=C2=A0 - Last paragraph: 4566 procedures apply to what? The text just said<= br> =C2=A0 =C2=A0 new categories are first-come-first server. I don=E2=80=99t t= hink
=C2=A0 =C2=A0 4566 set policies for how to change mux categories.

[Suhas] Agreed. I prefer= removing this line altogether. Please let me know=C2=A0

-15.2.1:
=C2=A0 How do you expect the table to look after adding this RFC to the
=C2=A0 references? Will this RFC be added to the entries in the MUX
=C2=A0 column?

= [Suhas] The plan was to add the reference to this RFC in the "Referenc= e Column"
=C2=A0

-16:
=C2=A0 - Do the assumptions for things like =E2=80=9Cfingerprint=E2=80=9D a= nd the zrtp
=C2=A0 =C2=A0 hash not have security considerations since they force multip= le
=C2=A0 =C2=A0 media streams to share the same security associations?
=C2=A0 =C2=A0 (Maybe that is covered by bundle?)

<= /div>
=C2=A0[Suhas] =C2=A0This should be covere= d in bundle spec.=C2=A0

=C2=A0 - 2nd paragraph: There are more than one srtp keying mechanism=E2=80= =94is
=C2=A0 =C2=A0 this assumed true for all of them?

[Suhas] =C2=A0SDES, DTLS doesn't violate RFC3711 and thus no two-time= pad. These are the currently defined mechanisms and thus i believe the sta= tement =C2=A0holds true. =C2=A0=C2=A0


# Editorial #

- xml2rfc reports some outdated references. Are those intentional?


[Suhas]=C2=A0<= span style=3D"font-family:Ubuntu;font-size:14.6667px;white-space:pre-wrap;l= ine-height:1.38;background-color:transparent">not intentional. will update = them
=C2=A0
- The abstract is more detailed than needed. The point is to describe the purpose of the draft. The second paragraph pretty much accomplishes that.

[Suhas] How do this rephrase look

=E2= =80=9CThe purpose of this specification is to provide a framework for= analyzing the multiplexing characteristics of SDP attributes when SDP is u= sed to negotiate the usage of single 5-tuple for sending and receiving medi= a associated with multiple media descriptions,. This specification also cat= egorizes the existing SDP attributes based on the framework described herei= n.=E2=80=9D


=C2=A0
- Please include table numbers.

[Suhas] Sure, =C2=A0= will do.

=C2=A0

- 1:
=C2=A0 - First paragraph:
=C2=A0 s/"This would for e.g."/This would, for example,"
=


[Suhas] Will change

=C2=A0
=C2=A0 s/"has made necessary to understand"/"has made it nec= essary to understand"

[Suhas] Will change

=C2=A0
=C2=A0 - 2nd paragraph:
=C2=A0 "Generic future-proof framework" - This seems excessive--c= an we just call
=C2=A0 it a framework?

[Suhas] Sure=C2= =A0

-3:
=C2=A0 =C2=A0 - 1st paragraph, first sentence: Convoluted sentence. Can it = be
=C2=A0 =C2=A0 simplified?

-4:
=C2=A0 =C2=A0 - first and second bullet example lists are each missing &quo= t;and".

-4.2, first paragraph: Sentence fragment. (same for several category
=C2=A0 descriptions.)

-4.4, first sentence: Spurious comma.

<= font face=3D"tahoma, sans-serif" color=3D"#0000ff">[Suhas] . Will fix these= as suggested
=C2=A0

-4.6, last paragraph: "In the above example, the category IDENTICAL is=
=C2=A0 =C2=A0inherited for the cpar encapsulated rtcp-mux attribute."<= br>
=C2=A0 =C2=A0"For" doesn't seem like the right proposition. I= s the category
=C2=A0 =C2=A0inherited "from" the cpar? "by" the cpar?<= br>

[Suhas] True . I will change it to "by" the cpar.= =C2=A0
=C2=A0

-5 and subsections: Is there any method to the ordering? They aren't =C2=A0 =C2=A0in RFC order. It might make sense to group by the nature of th= e
=C2=A0 =C2=A0attributes, but if that is the case here it's not explaine= d.


[Suhas]=C2=A0<= span style=3D"font-family:Ubuntu;font-size:14.6667px;white-space:pre-wrap;l= ine-height:1.38;background-color:transparent">These are not ordered as of t= oday. I can order th= e 5.X subsections by RFC order, if needed.

=C2= =A0
-5.4, note: "... due to inability in meeting
=C2=A0 =C2=A0the right resource reservations requested."

=C2=A0 =C2=A0I can't parse that clause. Does it mean "inability to= meet the
=C2=A0 =C2=A0resource reservation request"? "Inability to determi= ne the correct
=C2=A0 =C2=A0resource reservation request"?

<= /div>
[Suhas] It's the former. Will correct= it.
=C2=A0

-5.8, last paragraph:
=C2=A0 - "None of this is standardized yet and it wouldn=E2=80=99t wor= k
=C2=A0 as explained. "

=C2=A0 Does this mean that it has been explained why it wouldn't work?= =C2=A0
=C2=A0 Or do you mean the way it is explained wouldn't work?

[Suhas] . It means that i= t doesn't work for the reasons explained in this paragraph.
=C2=A0

-5.9:
=C2=A0 -s/"[RFC6773] document specifies"/"[RFC6773] specifie= s"
=C2=A0 - last paragraph: s/"can or cannot"/"may or may not&q= uot;

[Suhas] . = Sure will update
=C2=A0

-5.13, table:
=C2=A0 "Specific RTP extension document MUST be referred"


[Suhas] The id= ea was to mean that , one should refer to the specification that defines a = specific RTP extension in order to understand the multiplexing behavior.

Would the following rephrasing help instead

=
"Refer to the document defining spe= cific RTP Extension"

=C2=A0
=C2=A0 I don=E2=80=99t understand what that means. If you mean to
=C2=A0 =C2=A0say =E2=80=9Crefer to specific document=E2=80=9D, that shouldn= =E2=80=99t use MUST.

-5.22, table: "document needs to be referred" (several repetition= s)
=C2=A0 I'm not sure what this means. Should it say "Refer to the =C2=A0 specific document"?


Similarly= as above, would this reprhasing help=C2=A0

"Refer to the = document defining specific FEC Scheme

=C2=A0
-5.27, table: = If the "MUST be globally unique" requirement refers to
=C2=A0 and existing requirment from 4583, please avoid 2119 language.

[Suhas] Sure , will = update=C2=A0

-5.55: "... to be referred ..."
=C2=A0 I suggest "Refer to...."

[Suhas] Will do so=C2=A0

-6.3: "not clearly defined offer/answer usage"
=C2=A0 I'm not sure what is meant here. (Also, why is this not TBD or N= OT
=C2=A0 RECOMMENDED?)

[Suhas] Since RFC3890 b=3DTIAS is not = defined keeping O/A in mind, either the BUNDLE spec or this spec cannot def= ine its mux behavior. This is due to applicability of these specs under SD{= O/A usages alone.=C2=A0

I can rephrase the above as=C2=A0
"not defined under SDP Offer/Answ= er usage"=C2=A0
=C2=A0

-14.2.1, last paragraph:
=C2=A0 Do I understand this correctly to mean that the answerer can
=C2=A0 always fall back to a =E2=80=9Ccommon-to-all=E2=80=9D config even if= the offerer
=C2=A0 offered additional independent configs?

[Suhas]. Tha= t's a possibility if the answerer isn't able to use any of the addi= tional configurations offered=C2=A0

-14.3:
=C2=A0 s/"...extends capability..."/"...extends the capabili= ty..."

[Su= has] Will update
=C2=A0

-14.3.1: "which MUST be followed here as well."
=C2=A0 If bundle-negotiation already requires identical pt values,
=C2=A0 isn=E2=80=99t this MUST redundant to that one?


[Suhas] .= agreed and will reword
=C2=A0
14.3.2:
=C2=A0 I suspect that first MAY is a statement of fact, not a new
=C2=A0 requirement.

<= /font>
[Suhas] . agreed and will change t= o may instead of MAY
=C2=A0

-15, paragraph starting with "The IANA is requested to...":
=C2=A0 This sentence seems to belong with the next paragraph.

[Suhas] . Sure will move it =C2=A0

_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic

--94eb2c06eb86fa15bf0530e44d3c-- From nobody Thu Apr 21 10:51:44 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7094612E9B6; Thu, 21 Apr 2016 10:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 xhVGZMM3CLsG; Thu, 21 Apr 2016 10:51:42 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBAA612E9AE; Thu, 21 Apr 2016 10:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2183; q=dns/txt; s=iport; t=1461261101; x=1462470701; h=from:subject:to:cc:message-id:date:mime-version; bh=uzD7qMhfLy8ZiA6JxJ9+sUCd6AUU9FBx7CUOhCm45cQ=; b=M67lxAbxDSecZEEuk9wO0Gd47fy5TfJ5mc79OEzXrhzgCIjNPKcm8sAT uyVi1oWBz3e+RQsjA63mVArZjab9Vq8Og4sz5qqSazFrLIaipfT3AIW5k pVafrPhNksLcwGLp9Gx83LUPfJPWvBof8Ypkq0BeOkLJyvo5vX95kSzJc Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BMAgDVEhlX/51dJa1egzhTfbUJgmOCD?= =?us-ascii?q?wENgXQihWyBNjgUAQEBAQEBAWUnhEQnVQEfARwWCwILAwIBAgFLDQgBAYgmDq5?= =?us-ascii?q?9kR8BAQEBAQUBAQEBAQEBFQSGIYwKglYFmA+OFIFmhE2DBoVXhiOJCx4BAUKEB?= =?us-ascii?q?SAwAYh1AQEB?= X-IronPort-AV: E=Sophos;i="5.24,513,1454976000"; d="scan'208,217";a="264474995" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2016 17:51:41 +0000 Received: from [10.24.97.155] ([10.24.97.155]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u3LHpdWX012478; Thu, 21 Apr 2016 17:51:40 GMT From: Flemming Andreasen To: mmusic Message-ID: <5719132B.2020403@cisco.com> Date: Thu, 21 Apr 2016 13:51:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------030003000507020506030003" Archived-At: Cc: draft-ietf-mmusic-mux-exclusive@ietf.org Subject: [MMUSIC] WGLC on draft-ietf-mmusic-mux-exclusive-04 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 17:51:43 -0000 This is a multi-part message in MIME format. --------------030003000507020506030003 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Greetings MMUSIC We previously had a WGLC on draft-ietf-mmusic-mux-exclusive-03, which resulted in some comments. Those comments have since been resolved and the update has been submitted as draft-ietf-mmusic-mux-exclusive-04. We are now issuing a 1 week WGLC on this updated draft: https://www.ietf.org/id/draft-ietf-mmusic-mux-exclusive-04.txt as Proposed Standard. If you have any comments on the update, please provide them by Thursday, April 28, 2016. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well. Thanks -- Flemming (MMUSIC co-chair) --------------030003000507020506030003 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Greetings MMUSIC

We previously had a WGLC on draft-ietf-mmusic-mux-exclusive-03, which resulted in some comments. Those comments have since been resolved and the update has been submitted as draft-ietf-mmusic-mux-exclusive-04.

We are now issuing a 1 week WGLC on this updated draft:

    https://www.ietf.org/id/draft-ietf-mmusic-mux-exclusive-04.txt

as Proposed Standard. If you have any comments on the update, please provide them by Thursday, April 28, 2016.  Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well.

Thanks

-- Flemming (MMUSIC co-chair)
--------------030003000507020506030003-- From nobody Fri Apr 22 09:26:18 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89A312E82E for ; Fri, 22 Apr 2016 09:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 D_-A_CbRomg8 for ; Fri, 22 Apr 2016 09:26:15 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAAD212E804 for ; Fri, 22 Apr 2016 09:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=420; q=dns/txt; s=iport; t=1461342375; x=1462551975; h=from:subject:to:message-id:date:mime-version: content-transfer-encoding; bh=3l/rT9bVKfwFJT9ebC2xs2yMrQVa5DeXB0XgceF1X4M=; b=g7wwOA//447OIrY/pYK8ozKoaMJ7GR4DQRW3Xf0uVR6L1lOg/I1gmRFy 1aLuyP8SIdDzkDVp1YdT6UWy8Bd2jnKEcUZIWtth6D/ACPJ4cRQfnI46O PAYEuJl9DN1kdEV8Mi3d6P4KY+8N4dWUEafD0K0XyvobWgGtN8KzSKUv+ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAgBFTxpX/4gNJK1egzizJ4EdhDKCY?= =?us-ascii?q?AENgXOHOTgUAQEBAQEBAWUnhGsVQDYCBRYEBwILAwIBAgFLDQgBAYgmnm2PXZE?= =?us-ascii?q?iAQEBAQYCAR18hSWMCoJWAQSYD4EuiUGDJYFQFoRNgwaFV4E+hGWJDB4BAUKCN?= =?us-ascii?q?oFRIIkrAQEB?= X-IronPort-AV: E=Sophos;i="5.24,517,1454976000"; d="scan'208";a="96765824" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Apr 2016 16:26:14 +0000 Received: from [10.98.149.201] (bxb-fandreas-8818.cisco.com [10.98.149.201]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3MGQEUw020738 for ; Fri, 22 Apr 2016 16:26:14 GMT From: Flemming Andreasen To: mmusic Message-ID: <571A50A6.8000406@cisco.com> Date: Fri, 22 Apr 2016 12:26:14 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [MMUSIC] Confirming work item on multiple SDP 'fingerprint' attributes and adoption of draft-holmberg-mmusic-4572-update-01 as WG draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 16:26:17 -0000 Greetings During the MMUSIC meeting at IETF 95 in Buenos Aires, the MMUSIC WG participants indicated a strong consensus to 1) work on the multiple SDP 'fingerprint' attributes issue and 2) adopt draft-holmberg-mmusic-4572-update-01 as a WG draft for this work. If anybody has any objections to either of the above, please let us know by Friday, April 29, 2016. Thanks -- Bo & Flemming (MMUSIC chairs) From nobody Fri Apr 22 22:59:22 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E2512D710 for ; Fri, 22 Apr 2016 22:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cW9uf_0b5Ho9 for ; Fri, 22 Apr 2016 22:59:19 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54F2912D1AA for ; Fri, 22 Apr 2016 22:59:18 -0700 (PDT) X-AuditID: c1b4fb30-f79d86d0000062a1-5b-571b0f34e62c Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 3C.4E.25249.43F0B175; Sat, 23 Apr 2016 07:59:17 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.250]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0248.002; Sat, 23 Apr 2016 07:59:16 +0200 From: Bo Burman To: "mmusic (mmusic@ietf.org)" Thread-Topic: Draft IETF 95 MMUSIC minutes available Thread-Index: AdGdJKg5pVf7+faTST6EncMKMumjPw== Date: Sat, 23 Apr 2016 05:59:16 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22EAEB95DESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM2K7pa4pv3S4wbR+boupyx+zODB6LFny kymAMYrLJiU1J7MstUjfLoEr48H9c4wF28Qqlq2awNjAOFWki5GDQ0LAROLVA84uRk4gU0zi wr31bF2MXBxCAkcYJbbsbWaEcJYwSvzdOoEFpIpNQENi/o67jCC2iICBxOyVM8BsYQF9idk3 J0PFTSSufjzLDmHrSaw+ugusl0VAVeLQ0xYwm1fAV2LylvtgNqOArMT97/fAbGYBcYlbT+Yz QVwkILFkz3lmCFtU4uXjf6wQtpLEiu2XGCHq8yUmPW5ih5gpKHFy5hOWCYxCs5CMmoWkbBaS Moi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQT IzAmDm75bbCD8eVzx0OMAhyMSjy8C1olw4VYE8uKK3MPMUpwMCuJ8DJwS4cL8aYkVlalFuXH F5XmpBYfYpTmYFES582O/BcmJJCeWJKanZpakFoEk2Xi4JRqYMzxuLX13/8QjwiFtujpWfsf FJl1bZZc6zzvZe9njbdrrxX/d1g8O0mWMTbl58G0agnxUysucjytLz8lknxr1ZnSxOvzy8XK ViU+u/PirEuC3LG5zTWXltiz3O1JzT0nUdE455aulRm7ve8bB+ZTjYoqP2UzFrL2WHh828hW cXglf/zl5fwHTZRYijMSDbWYi4oTAe1Kj4uFAgAA Archived-At: Subject: [MMUSIC] Draft IETF 95 MMUSIC minutes available X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 05:59:21 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22EAEB95DESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you Magnus and Roni for taking notes. https://www.ietf.org/proceedings/95/minutes/minutes-95-mmusic Please provide any feedback. Cheers, /Bo and Flemming (MMUSIC chairs) --_000_BBE9739C2C302046BD34B42713A1E2A22EAEB95DESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you Magnus and Roni for taking notes.

 

https://www.ie= tf.org/proceedings/95/minutes/minutes-95-mmusic

 

Please provide any feedback.

 

Cheers,

/Bo and Flemming (MMUSIC chairs)

 

--_000_BBE9739C2C302046BD34B42713A1E2A22EAEB95DESESSMB105erics_-- From nobody Mon Apr 25 05:59:20 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807FB12D5B0 for ; Mon, 25 Apr 2016 05:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzvSLK7QOAlO for ; Mon, 25 Apr 2016 05:59:18 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4FAA12D1E3 for ; Mon, 25 Apr 2016 05:59:17 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-40-571e14a37df6 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C1.31.12926.3A41E175; Mon, 25 Apr 2016 14:59:16 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Mon, 25 Apr 2016 14:59:15 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: DTLS-SDP: "actress" to always trigger new DTLS association? Thread-Index: AQHRnvJFE9/VC7yRi0qI3xYwkFAAig== Date: Mon, 25 Apr 2016 12:59:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D343EF9877BEchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbFdTneJiFy4wZc1PBZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtPpl9kLJohU7GyYyNjA+FKgi5GTQ0LAROJ9x3pWCFtM4sK9 9WxdjFwcQgJHGCW6dk1hhXCWMEqsPrSevYuRg4NNwEKi+582SIOIgLrE1709zCC2sICLxPEj V1gg4p4SryfOYYew9SQev/3PDNLKIqAqsXVOKkiYV8BK4vaPp2AljEB7v59awwRiMwuIS9x6 Mp8J4h4BiSV7zjND2KISLx//A7tTFGjkvhfnGSHiihLtTxsYIXrjJT6e/MIGMV9Q4uTMJywT GIVnIRk7C0nZLCRlEHEDiffn5jND2NoSyxa+hrL1JTZ+OcsIYVtLHD2whQlZzQJGjlWMosWp xUm56UbGeqlFmcnFxfl5enmpJZsYgRF0cMtv1R2Ml984HmIU4GBU4uFdwCkbLsSaWFZcmXuI UYKDWUmEdzmfXLgQb0piZVVqUX58UWlOavEhRmkOFiVx3uzIf2FCAumJJanZqakFqUUwWSYO TqkGRtkpgnXKu6Kvi7fZrijwM79bk+ueJ3Wwq6zOdVP8156U+I+fPyp4ztt++exPQXsDOQne tM5Ze3mlVsjkG3jMsNn0l7vM21Yx+NR8v//XYl7PPHJk6UVpAf9p6i0y/Yy9qyTe/Hzvf8D0 DlNig69O87S6iqUX9OV013Klfutj/WW+w3Lbv998SizFGYmGWsxFxYkAhZe4kpwCAAA= Archived-At: Subject: [MMUSIC] DTLS-SDP: "actress" to always trigger new DTLS association? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 12:59:19 -0000 --_000_D343EF9877BEchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Assume that Alice and Bob have negotiated a DTLS association. Alice has the= =93active=94 role, and Bob has the =93passive=94 role. Now, if Alice sends a new offer, with =93passive=94, the roles will change = and the DTLS association will have to be re-established. If Alice in the new offer sends =93actpass=94, it is yet not known whether = the roles will change. However, as the roles MAY change, it has been suggested that the fingerprin= t/dtls-assocation-id combination needs to be updated in the offer =96 which= by itself requires a new DTLS association :) MY QUESTION: Is there a case for sending =93actpass=94 without the intentio= n of establishing a new DTLS association =96 no matter if the roles change = or not? Regards, Christer --_000_D343EF9877BEchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

Assume that Alice and Bob have negotiated a DTLS association. Alice ha= s the =93active=94 role, and Bob has the =93passive=94 role.

Now, if Alice sends a new offer, with =93passive=94, the roles will ch= ange and the DTLS association will have to be re-established.

If Alice in the new offer sends =93actpass=94, it is yet not known whe= ther the roles will change. 

However, as the roles MAY change, it has been suggested that the finge= rprint/dtls-assocation-id combination needs to be updated in the offer =96 = which by itself requires a new DTLS association :)

MY QUESTION: Is there a case for sending =93actpass=94 without the int= ention of establishing a new DTLS association =96 no matter if the roles ch= ange or not?

Regards,

Christer




--_000_D343EF9877BEchristerholmbergericssoncom_-- From nobody Mon Apr 25 06:01:40 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A70C12D5CA for ; Mon, 25 Apr 2016 06:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEgkoF6glBJk for ; Mon, 25 Apr 2016 06:01:37 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6015D12D5AC for ; Mon, 25 Apr 2016 06:01:37 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-82-571e152ee1f7 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 96.F0.27088.E251E175; Mon, 25 Apr 2016 15:01:35 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0248.002; Mon, 25 Apr 2016 15:01:34 +0200 From: Christer Holmberg To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] DTLS-SDP: "actress" to always trigger new DTLS association? Thread-Index: AQHRnvKYXFB5h7XpQUSnHRe8275X5Q== Date: Mon, 25 Apr 2016 13:01:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D343EFEE77C1christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGbFdQldfVC7cYO4nOYupyx+zODB6LFny kymAMYrLJiU1J7MstUjfLoEr48SKycwFH5QqDh97yN7A+EG2i5GDQ0LARGJfU0kXIyeQKSZx 4d56ti5GLg4hgSOMEk2Nc5khnCWMEs9ubWIHaWATsJDo/qcN0iAiECvxdd17JhBbWCBY4vfL X8wQ8RCJD3tWM0HYehK/l/0As1kEVCWent7IBmLzClhJ3JvQxwpiMwIt/n5qDVgNs4C4xK0n 85kgDhKQWLLnPDOELSrx8vE/sHpRoJn7XpxnhLhfSWLa1jSI1niJ1okTocYLSpyc+YRlAqPw LCRTZyEpm4WkDCJuIPH+3HxmCFtbYtnC11C2vsTGL2cZIWxriQcb/rMgq1nAyLGKUbQ4tTgp N93ISC+1KDO5uDg/Ty8vtWQTIzB+Dm75bbCD8eVzx0OMAhyMSjy8Czhlw4VYE8uKK3MPMUpw MCuJ8C7nkwsX4k1JrKxKLcqPLyrNSS0+xCjNwaIkzpsd+S9MSCA9sSQ1OzW1ILUIJsvEwSnV wLjFyXPDrI6ZS8Qa+tf8OHE25vzBJu8XPwoqP6++c5mDc/vP1skt+34EdeunX4y5obn2ssb8 v6pSixlerYx8k7qgW6zpkWgvo+fqggrzReWnNspec1k68dTfTW+eSuYHXomwZjpcVs8lW3HR fbF6x6mST0pcrE/fKTu6TWexUr4heTbZLCXcNUeJpTgj0VCLuag4EQB+eXhAmwIAAA== Archived-At: Subject: Re: [MMUSIC] DTLS-SDP: "actress" to always trigger new DTLS association? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 13:01:39 -0000 --_000_D343EFEE77C1christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The subject should obviously say =93actpass=94 :) Regards, Christer From: mmusic > on b= ehalf of Christer Holmberg > Date: Monday 25 April 2016 at 15:59 To: "mmusic@ietf.org" > Subject: [MMUSIC] DTLS-SDP: "actress" to always trigger new DTLS associatio= n? Hi, Assume that Alice and Bob have negotiated a DTLS association. Alice has the= =93active=94 role, and Bob has the =93passive=94 role. Now, if Alice sends a new offer, with =93passive=94, the roles will change = and the DTLS association will have to be re-established. If Alice in the new offer sends =93actpass=94, it is yet not known whether = the roles will change. However, as the roles MAY change, it has been suggested that the fingerprin= t/dtls-assocation-id combination needs to be updated in the offer =96 which= by itself requires a new DTLS association :) MY QUESTION: Is there a case for sending =93actpass=94 without the intentio= n of establishing a new DTLS association =96 no matter if the roles change = or not? Regards, Christer --_000_D343EFEE77C1christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <645FB2A863CC734EADE433472E6B6382@ericsson.com> Content-Transfer-Encoding: quoted-printable
The subject should obviously say =93actpass=94 :)

Regards,

Christer


From: mmusic <mmusic-bounces@ietf.org> on behalf of Chris= ter Holmberg <christer= .holmberg@ericsson.com>
Date: Monday 25 April 2016 at 15:59=
To: "mmusic@ietf.org" <= mmusic@ietf.org>
Subject: [MMUSIC] DTLS-SDP: "a= ctress" to always trigger new DTLS association?

Hi,

Assume that Alice and Bob have negotiated a DTLS association. Alice ha= s the =93active=94 role, and Bob has the =93passive=94 role.

Now, if Alice sends a new offer, with =93passive=94, the roles will ch= ange and the DTLS association will have to be re-established.

If Alice in the new offer sends =93actpass=94, it is yet not known whe= ther the roles will change. 

However, as the roles MAY change, it has been suggested that the finge= rprint/dtls-assocation-id combination needs to be updated in the offer =96 = which by itself requires a new DTLS association :)

MY QUESTION: Is there a case for sending =93actpass=94 without the int= ention of establishing a new DTLS association =96 no matter if the roles ch= ange or not?

Regards,

Christer




 --_000_D343EFEE77C1christerholmbergericssoncom_-- From nobody Mon Apr 25 06:38:40 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4378112D1BB for ; Mon, 25 Apr 2016 06:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 gjJHkYMNCKW9 for ; Mon, 25 Apr 2016 06:38:37 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AE7312B014 for ; Mon, 25 Apr 2016 06:38:36 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-74-571e1ddaad60 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 6F.07.18043.ADD1E175; Mon, 25 Apr 2016 15:38:34 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Mon, 25 Apr 2016 15:38:34 +0200 From: Christer Holmberg To: Roman Shpount , Paul Kyzivat Thread-Topic: [MMUSIC] 4572 update: forbid weak hashes? Thread-Index: AQHRkMlvyALEPXgXDkKRhXLaT8/AmJ9+gkOg///n5gCAACIUsP//4eqAgAB6NgCAASWpgIAARJyAgBqMZgA= Date: Mon, 25 Apr 2016 13:38:34 +0000 Message-ID: References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F27D6E@ESESSMB209.ericsson.se> <4F76BA3A-A69A-473E-97DA-287E6E571324@iii.ca> <5707C985.5060809@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D343F76477D5christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAIsWRmVeSWpSXmKPExsUyM2K7nO4tWblwg1NHjS2mLn/MYrFiwwFW ixkXpjI7MHv8ff+ByWPJkp9MHremFAQwR3HZpKTmZJalFunbJXBlbFm/i7lgY0TFsa1TmBoY L3t1MXJySAiYSLyf8IcRwhaTuHBvPRuILSRwhFFic1tRFyMXkL2EUeJF8yXmLkYODjYBC4nu f9ogNSIC3hJ9fR3sIGFmAXWJq4uDQMLCAmYSn673sUGUmEv8bGhkgbCTJM492gkWZxFQlfj+ 7j6YzStgJXHi011WiFWvmSWurnsGluAUCJSYvK8N7DZGoNu+n1rDBGIzC4hL3HoynwniZgGJ JXvOM0PYohIvH/9jBbFFBfQk9r04D/WXksSPDZdYIHrjJe7v3soKsVhQ4uTMJywTGMVmIRk7 C0nZLCRlEHEDiffn5jND2NoSyxa+hrL1JTZ+OcsIYVtLNHy7zISsZgEjxypG0eLU4uLcdCMj vdSizOTi4vw8vbzUkk2MwHg9uOW31Q7Gg88dDzEKcDAq8fAu4JQNF2JNLCuuzD3EKMHBrCTC u0BGLlyINyWxsiq1KD++qDQntfgQozQHi5I4b07kvzAhgfTEktTs1NSC1CKYLBMHp1QDo8Id VZPWTR+F/npErbl0l6MhaV7SIh7r3Wkcn66kH1+bF/jN5agwV6bt1V3pbyMX2q0OCTq0vLE2 81lpwt/4dNZpc1y84t9ciWkLvVLVFrCHQY79y7fH+p1Ptqr/e3nx5aIfWp02Kya+f3M4MPM2 283WnmdCk5eI5V9l5zPM8ztwsf9MQ034FCWW4oxEQy3mouJEAL76uhXTAgAA Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 13:38:39 -0000 --_000_D343F76477D5christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I think option 1) does not support hash agility =96 which is one of the mai= n reason from sending multiple fingerprints to begin with =96 as it assumes= that the sender and receiver will support the same hash functions. Option 2) seems to be what Cullen also suggested: as long as there is at le= ast one fingerprint (calculated using a has function which the receiver con= siders secure enough) that matches the DTLS association. So, in general I s= upport option 2). However, we need to keep in mind that there may be fingerprints sent for mu= ltiple certificates. Do we need to mandate at least one match per cerfifica= te? Regards, Christer From: mmusic > on b= ehalf of Roman Shpount > Date: Friday 8 April 2016 at 22:14 To: "pkyzivat@alum.mit.edu" > Cc: "mmusic@ietf.org" > Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? I just wanted to re-iterate the question. We have two options: 1. If m=3D line has multiple fingerprints with hash functions X, Y, Z, at l= east one fingerprint with each function must match DTLS association for the= media to be accepted. For example, if m=3D line has two fingerprints with = hash function SHA-1, and two with SHA-512, DTLS association certificate mus= t match at least one SHA-1 and one SHA-512 fingerprint. 2. If m=3D line has multiple fingerprints with hash functions X, Y, Z, at l= east one fingerprint with any hash function which is considered secure enou= gh must match DTLS association for the media to be accepted. For example, i= f m=3D line has two fingerprints with hash function SHA-1, and two with SHA= -512, DTLS association certificate must match one of either SHA-1 or SHA-51= 2 fingerprints. Option 1 has a benefit of being more secure since it provides the combined = secure of individual hash functions. It does put additional restrictions ho= w equipment can be combined into producing a single m=3D line. For instance= if fingerprints from two servers are combined into a single m=3D line and = it is not known in advance which one will be used, both servers will need t= o always support the same hash functions and be updated at the same time. Option 2 is less secure since it is only as secure as the least secure hash= . On the other hand option 2 allows to be more flexible in how equipment is= combined to form the single m=3D line. Two servers in above example, for i= nstance, can support different hash functions. I would ask the group to state their preferences. I prefer option 2 but can live with option 1. Regards, _____________ Roman Shpount On Fri, Apr 8, 2016 at 11:08 AM, Paul Kyzivat > wrote: I don't have a horse in this race. I think those of you who do need to fini= sh deciding what the rules are for multiple fingerprints, and then write th= e result into the draft update. Clearly it is ambiguous at the moment. Thanks, Paul On 4/7/16 5:37 PM, Cullen Jennings wrote: On Apr 7, 2016, at 11:20 AM, Roman Shpount >> wrote: You should check all the hashes you consider secure and if any one of them matches the DTLS association certificate, accept the media. +1 This allows us to do things like include hash for two servers even when you re not sure which server will actually be used. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_D343F76477D5christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <727BD45CCC21204B805983F52D59BB2B@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

 --089e0118275410098105316894c3-- From nobody Fri Apr 29 11:32:24 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C837E12D6F6; Fri, 29 Apr 2016 11:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 s_aj1ISqNg4u; Fri, 29 Apr 2016 11:32:13 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF08612D6EF; Fri, 29 Apr 2016 11:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=707; q=dns/txt; s=iport; t=1461954732; x=1463164332; h=from:subject:to:cc:message-id:date:mime-version: content-transfer-encoding; bh=ZfF6USqFk3RDluo0CVlc/x3D8ySTmhHKBuegNoK8bW0=; b=Gw1i0fCanKbCZBC0aWl9JuTX2/lsfuy9BCICHX/EyCROFpgoancbRn12 FRMzIZdA+6nVvmv/jUqAT9VKokFyFqOK4oOYL3HIhYF8mhrbNS6RnR9+E MPAHRDYZnn3rsOWLWyTkCcvkb5ptSD0WhwByaLQOtyCkY9svshue/jcJZ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgD0pyNX/5RdJa1dgzh+szCFBYIPA?= =?us-ascii?q?Q2BdoYQgS84FAEBAQEBAQFlJ4RlBhVBNQImAl8NCAEBiCazQZEjAQEBAQEFAQE?= =?us-ascii?q?BARx8hSWBdgiKC4JWAQSYE4pygyUCgWWETYMGhDyBG48wHgEBQoQHIIkxAQEB?= X-IronPort-AV: E=Sophos;i="5.24,552,1454976000"; d="scan'208";a="102098712" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Apr 2016 18:32:12 +0000 Received: from [10.98.149.201] (bxb-fandreas-8818.cisco.com [10.98.149.201]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3TIWBNP018359; Fri, 29 Apr 2016 18:32:11 GMT From: Flemming Andreasen To: mmusic Message-ID: <90408933-ab1d-8636-9dfb-1b75443a04b8@cisco.com> Date: Fri, 29 Apr 2016 14:32:11 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-29 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 18:32:16 -0000 Greetings This is to announce a 2 week Working Last Call for draft-ietf-mmusic-sdp-bundle-negotiation-29 as Proposed Standard. Please note that we previously issued a WGLC on the -22 version (in June 2015), however, since there has been various updates since then, we want to give people a chance to properly review the current version one last time (hopefully). Please review and provide any comments you may have on the document by Friday, May 13, 2016. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well. Thanks Flemming (MMUSIC co-chair) From nobody Fri Apr 29 19:48:14 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4745112D796; Fri, 29 Apr 2016 19:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.898 X-Spam-Level: X-Spam-Status: No, score=-107.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 Br3ICT-YuYB9; Fri, 29 Apr 2016 19:47:59 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4436012D78E; Fri, 29 Apr 2016 19:47:59 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D3EE9180094; Fri, 29 Apr 2016 19:47:38 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160430024738.D3EE9180094@rfc-editor.org> Date: Fri, 29 Apr 2016 19:47:38 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, mmusic@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] RFC 7850 on Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 02:48:04 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7850 Title: Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles Author: S. Nandakumar Status: Standards Track Stream: IETF Date: April 2016 Mailbox: snandaku@cisco.com Pages: 7 Characters: 15190 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mmusic-proto-iana-registration-06.txt URL: https://www.rfc-editor.org/info/rfc7850 DOI: http://dx.doi.org/10.17487/RFC7850 The Real-time Transport Protocol (RTP) specification establishes a registry of profile names for use by higher-level control protocols, such as the Session Description Protocol (SDP), to refer to the transport methods. This specification describes the following new SDP transport protocol identifiers for transporting RTP Media over TCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF', 'TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP', and 'TCP/TLS/RTP/AVPF'. This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
I think option 1) does not support hash agility =96 which is one of th= e main reason from sending multiple fingerprints to begin with =96 as it as= sumes that the sender and receiver will support the same hash functions.

Option 2) seems to be what Cullen also suggested: as long as there is = at least one fingerprint (calculated using a has function which the receive= r considers secure enough) that matches the DTLS association. So, in genera= l I support option 2).

However, we need to keep in mind that there may be fingerprints sent f= or multiple certificates. Do we need to mandate at least one match per cerf= ificate?

Regards,

Christer



From: mmusic <mmusic-bounces@ietf.org> on behalf of Roman= Shpount <roman@telurix.com>=
Date: Friday 8 April 2016 at 22:14<= br> To: "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>
Cc: "mmusic@ietf.org" <= mmusic@ietf.org>
Subject: Re: [MMUSIC] 4572 update: = forbid weak hashes?

I just wanted to re-iterate the question. We have two opti= ons:

1. If m=3D line has multiple fingerprints with hash functions X, Y, Z,= at least one fingerprint with each function must match DTLS association fo= r the media to be accepted. For example, if m=3D line has two fingerprints = with hash function SHA-1, and two with SHA-512, DTLS association certificate must match at least one SHA-1 and on= e SHA-512 fingerprint.

2. If m=3D line has multiple fingerprints with hash functions X, Y, Z,= at least one fingerprint with any hash function which is considered secure= enough must match DTLS association for the media to be accepted. For examp= le, if m=3D line has two fingerprints with hash function SHA-1, and two with SHA-512, DTLS association certifica= te must match one of either SHA-1 or SHA-512 fingerprints.

Option 1 has a benefit of being more secure since it provides the comb= ined secure of individual hash functions. It does put additional restrictio= ns how equipment can be combined into producing a single m=3D line. For ins= tance if fingerprints from two servers are combined into a single m=3D line and it is not known in advance which = one will be used, both servers will need to always support the same hash fu= nctions and be updated at the same time.

Option 2 is less secure since it is only as secure as the least secure= hash. On the other hand option 2 allows to be more flexible in how equipme= nt is combined to form the single m=3D line. Two servers in above example, = for instance, can support different hash functions.

I would ask the group to state their preferences.

I prefer option 2 but can live with option 1. 

Regards,

_____________
Roman Shpount

On Fri, Apr 8, 2016 at 11:08 AM, Paul Kyzivat <pkyzivat@alu= m.mit.edu> wrote:
I don't have a horse in this race. I think those of you who do need to fini= sh deciding what the rules are for multiple fingerprints, and then write th= e result into the draft update. Clearly it is ambiguous at the moment.

        Thanks,
        Paul

On 4/7/16 5:37 PM, Cullen Jennings wrote:

On Apr 7, 2016, at 11:20 AM, Roman Shpount <roman@telurix.com
<mailto:roman@telurix.com>> wrote:

You should check all the hashes you consider secure and if any one of
them matches the DTLS association certificate, accept the media.

+1

This allows us to do things like include hash for two servers even when
you re not sure which server will actually be used.




_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic


_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic

 --_000_D343F76477D5christerholmbergericssoncom_-- From nobody Mon Apr 25 07:36:53 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE3312D600 for ; Mon, 25 Apr 2016 07:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 XyfBBNDerrmM for ; Mon, 25 Apr 2016 07:36:47 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2732F12D5ED for ; Mon, 25 Apr 2016 07:36:47 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id u185so185427652iod.3 for ; Mon, 25 Apr 2016 07:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=rUMzjTMHVKx2m1gqMVuWSHmxymylw1DHV8GJFFjWeIY=; b=brnrLYbC1ZGJdXQKhxGXwlU2AvBqTc2K9ZxTWRf/7vptIFsf/s09cZ+CAf6DFAXY32 eL5Bz4BVbPtfg5BtyHRf4FZY+KQ5YOfxLGcoYw4/OJVUaf/sRdbM3k6+h0qmPtwbxffN 381TpkqTlTzGP8WJT3uomjWhJtRI5R4kOY5OKD80b6rhne7vrOfScBMeHz+sS4chZeH2 YAnXQXgt86asFlBsw5jUylQWNwxyXhJVJKsX2xF60iNBlRlcw7pp581SopxCooxj/rjX U/kTA6QOVjsRCSNoGL2ut4GJzeGSzFoO1InFZa4tqbKvrmrL/HtWDG17j4GGS8JXNP6w TAdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=rUMzjTMHVKx2m1gqMVuWSHmxymylw1DHV8GJFFjWeIY=; b=BZjPArSpKIOhGpcpBLVDvEkLkEEZbIje4SSsUUWH00uHvVZB4cQ+Ud3snFztH37wFv cb1IVLoYv+vZBMuDXh2BJ78dziqGwB+cGmYVGOYP+cWtNocfyxAZKjp8hhDy0xya3lnA bwwGIYcJ/nebtBpq2oJ3t5E8j32j71PkjmW3JuhV+3gOf3xc6B/AH+NpsatvWj3pU1oR 1Ben4xqA7SpcOGXOgUs/IWOuz3f7aj2D97aoS2C7UFOHpN6SjdscxQpd0EiHBctfx7cy HquiI3AXjrHrddtvcFMs6nO/hv2/eWzWBL4HmdhDKJpRMLecLcIbL+WBTQ9zPb0sYOW6 F4cw== X-Gm-Message-State: AOPr4FUiO69xKhxWkNDFh9F5ss4eL5494rX+Q0Z8BlvxTga+Xb2sknW4LLPYur+85uv6Yw== X-Received: by 10.107.34.65 with SMTP id i62mr36361337ioi.39.1461595006034; Mon, 25 Apr 2016 07:36:46 -0700 (PDT) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com. [209.85.213.172]) by smtp.gmail.com with ESMTPSA id k4sm2879568igf.11.2016.04.25.07.36.45 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2016 07:36:45 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id g8so75639603igr.0 for ; Mon, 25 Apr 2016 07:36:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.78.73 with SMTP id z9mr12813820igw.42.1461595004892; Mon, 25 Apr 2016 07:36:44 -0700 (PDT) Received: by 10.36.144.69 with HTTP; Mon, 25 Apr 2016 07:36:44 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Apr 2016 10:36:44 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e0118275412a6ac0531501b20 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-SDP: "actress" to always trigger new DTLS association? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 14:36:49 -0000 --089e0118275412a6ac0531501b20 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Christer, This is a very common topic ofr confusion. See https://github.com/rtcweb-wg/jsep/issues/72 for a similar discussion. The whole issue is that answerer can initiate a new DTLS association. So if offerer generates an offer that allows an answerer start a new DTLS association, i.e. an offer without ICE or offer with ICE restart, this offer should have actpass. Without actpass role, the answerer when starting a new DTLS association would have to reuse the old negotiated role, which, if answerer was previously passive, can slow down the association setup by half a round trip. So, basic rules should be: 1. Do not change fingerprints/association-id unless you want to setup a new DTLS association. 2. Set the setup role to actpass if answerer MAY initiate a new DTLS association 3. Getting a setup role actpass is not enough to start a new DTLS association. Change of negotiated role, i.e. change of answerer's setup role, is necessary as a condition for setting up new DTLS association. Setting up a new DTLS association on role change only is for backwards compatibility only and should be discouraged. Regards, _____________ Roman Shpount On Mon, Apr 25, 2016 at 8:59 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > Assume that Alice and Bob have negotiated a DTLS association. Alice has > the =E2=80=9Cactive=E2=80=9D role, and Bob has the =E2=80=9Cpassive=E2=80= =9D role. > > Now, if Alice sends a new offer, with =E2=80=9Cpassive=E2=80=9D, the role= s will change and > the DTLS association will have to be re-established. > > If Alice in the new offer sends =E2=80=9Cactpass=E2=80=9D, it is yet not = known whether the > roles will change. > > However, as the roles MAY change, it has been suggested that the > fingerprint/dtls-assocation-id combination needs to be updated in the off= er > =E2=80=93 which by itself requires a new DTLS association :) > > MY QUESTION: Is there a case for sending =E2=80=9Cactpass=E2=80=9D withou= t the intention > of establishing a new DTLS association =E2=80=93 no matter if the roles c= hange or > not? > > Regards, > > Christer > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --089e0118275412a6ac0531501b20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Christer,

This is a very common topic o= fr confusion. See=C2=A0https://github.com/rtcweb-wg/jsep/issues/72 for a similar discussio= n.

The whole issue is that answerer can initiate a= new DTLS association. So if offerer generates an offer that allows an answ= erer start a new DTLS association, i.e. an offer without ICE or offer with = ICE restart, this offer should have actpass. Without actpass role, the answ= erer when starting a new DTLS association would have to reuse the old negot= iated role, which, if answerer was previously passive, can slow down the as= sociation setup by half a round trip.

So, basic ru= les should be:
1. Do not change fingerprints/association-id unles= s you want to setup a new DTLS association.
2. Set the setup role= to actpass if answerer MAY initiate a new DTLS association
3. Ge= tting a setup role actpass is not enough to start a new DTLS association. C= hange of negotiated role, i.e. change of answerer's setup role, is nece= ssary as a condition for setting up new DTLS association.

Setting up a new DTLS association on role change only is for backwa= rds compatibility only and should be discouraged.

= Regards,=C2=A0



_________= ____
Roman Shpount

On Mon, Apr 25, 2016 at 8:59 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>
Hi,

Assume that Alice and Bob have negotiated a DTLS association. Alice ha= s the =E2=80=9Cactive=E2=80=9D role, and Bob has the =E2=80=9Cpassive=E2=80= =9D role.

Now, if Alice sends a new offer, with =E2=80=9Cpassive=E2=80=9D, the r= oles will change and the DTLS association will have to be re-established.

If Alice in the new offer sends =E2=80=9Cactpass=E2=80=9D, it is yet n= ot known whether the roles will change.=C2=A0

However, as the roles MAY change, it has been suggested that the finge= rprint/dtls-assocation-id combination needs to be updated in the offer =E2= =80=93 which by itself requires a new DTLS association :)

MY QUESTION: Is there a case for sending =E2=80=9Cactpass=E2=80=9D wit= hout the intention of establishing a new DTLS association =E2=80=93 no matt= er if the roles change or not?

Regards,

Christer





_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


--089e0118275412a6ac0531501b20-- From nobody Mon Apr 25 07:47:49 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B3212D1B0 for ; Mon, 25 Apr 2016 07:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 0Q2s4qgQwMvT for ; Mon, 25 Apr 2016 07:47:41 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711F212D501 for ; Mon, 25 Apr 2016 07:47:41 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id x201so178337724oif.3 for ; Mon, 25 Apr 2016 07:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=6+IBCY5mPogisTSZM2FYbtec/q0i89PK4a38ewb9jXM=; b=vvSORwyMuqKoQ0kVN7W0b3ArKCaDTChY5u3WIZqdbHSr7eFia8dfubDq26GnKy2feX qUk6mv7trbHoN3VDH7/aO10yElnc4ed+tP6Q2ouciU32wTDYI160shtUzCj6oqvCqIRY t9ygJGwtV8VmywT+f8fMhOqJirCN4HF6q/hIX4+eMgaybHmyz7mcRMjMz+5S2r0rkyQi 7hcpzHVZRnGRFO4NOHMdUBOCp89eqYbqN2tMNEJ991cvdd5RN1u706WC+3ERllu+SxZN jgWfC/Uw5cu7dt8xGfQtNjY+OB58Jbp/MhWWhR92Y4WSgrrwLcpQcexs7eSm1CAmk1IS khbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=6+IBCY5mPogisTSZM2FYbtec/q0i89PK4a38ewb9jXM=; b=EOxtfrO59Wq4pWeNx9jq2wc0Dw2Rld5B06cgRhZXlUePiplRR0nFZxZhF2Rvcqg5KZ iMPpi3rB85uRa5HQUTEAM8xRa2f6TI7rPT8yXSdHsmigAMvUzzoVmHjk4GlZ60M8QUis /xn/bUAChExylK4M9Aupf8OL19Ou7TSkdMVn8NdMa+i1tKscmmE5EuqPqUwfhEFtSML0 yFvQJCjrdKc5aiojTENehVV8hwWYS4SYNx7r2QN/VE9HdK832mWJwocd+wHP/I9s9cD2 +1yzM/1V2OQQHHubWlgtJr2fSE1w9RH8aenlM87646Ucnd3ULGdIAlP0b5erKYaoEWoH qvvA== X-Gm-Message-State: AOPr4FWz8a5HhfcjwsZGWYeEgm3JQCw7AbsnIHOEemYJI8IQeIGY3ZB0iiHp02x2QuXDYQ== X-Received: by 10.157.15.226 with SMTP id m31mr2963319otd.31.1461595660754; Mon, 25 Apr 2016 07:47:40 -0700 (PDT) Received: from mail-io0-f180.google.com (mail-io0-f180.google.com. [209.85.223.180]) by smtp.gmail.com with ESMTPSA id a34sm6468513otb.1.2016.04.25.07.47.40 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2016 07:47:40 -0700 (PDT) Received: by mail-io0-f180.google.com with SMTP id u185so185802363iod.3 for ; Mon, 25 Apr 2016 07:47:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.147.7 with SMTP id v7mr6645135iod.3.1461595659813; Mon, 25 Apr 2016 07:47:39 -0700 (PDT) Received: by 10.36.144.69 with HTTP; Mon, 25 Apr 2016 07:47:39 -0700 (PDT) In-Reply-To: References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F27D6E@ESESSMB209.ericsson.se> <4F76BA3A-A69A-473E-97DA-287E6E571324@iii.ca> <5707C985.5060809@alum.mit.edu> Date: Mon, 25 Apr 2016 10:47:39 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c055f681bd0c405315042ea Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 14:47:48 -0000 --94eb2c055f681bd0c405315042ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Christer, There is no indication what fingerprint applies to what certificate in SDP fingerprint attribute. The rule should be if connection is established a certificate which matches at least one hash that you consider secure, the connection should be accepted. If you would make it more complicated, this will likely break backwards interop or would require changes to fingerprint/DTLS/certificates. Regards, _____________ Roman Shpount On Mon, Apr 25, 2016 at 9:38 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > I think option 1) does not support hash agility =E2=80=93 which is one of= the main > reason from sending multiple fingerprints to begin with =E2=80=93 as it a= ssumes > that the sender and receiver will support the same hash functions. > > Option 2) seems to be what Cullen also suggested: as long as there is at > least one fingerprint (calculated using a has function which the receiver > considers secure enough) that matches the DTLS association. So, in genera= l > I support option 2). > > However, we need to keep in mind that there may be fingerprints sent for > multiple certificates. Do we need to mandate at least one match per > cerfificate? > > Regards, > > Christer > > > > From: mmusic on behalf of Roman Shpount < > roman@telurix.com> > Date: Friday 8 April 2016 at 22:14 > To: "pkyzivat@alum.mit.edu" > Cc: "mmusic@ietf.org" > Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? > > I just wanted to re-iterate the question. We have two options: > > 1. If m=3D line has multiple fingerprints with hash functions X, Y, Z, at > least one fingerprint with each function must match DTLS association for > the media to be accepted. For example, if m=3D line has two fingerprints = with > hash function SHA-1, and two with SHA-512, DTLS association certificate > must match at least one SHA-1 and one SHA-512 fingerprint. > > 2. If m=3D line has multiple fingerprints with hash functions X, Y, Z, at > least one fingerprint with any hash function which is considered secure > enough must match DTLS association for the media to be accepted. For > example, if m=3D line has two fingerprints with hash function SHA-1, and = two > with SHA-512, DTLS association certificate must match one of either SHA-1 > or SHA-512 fingerprints. > > Option 1 has a benefit of being more secure since it provides the combine= d > secure of individual hash functions. It does put additional restrictions > how equipment can be combined into producing a single m=3D line. For inst= ance > if fingerprints from two servers are combined into a single m=3D line and= it > is not known in advance which one will be used, both servers will need to > always support the same hash functions and be updated at the same time. > > Option 2 is less secure since it is only as secure as the least secure > hash. On the other hand option 2 allows to be more flexible in how > equipment is combined to form the single m=3D line. Two servers in above > example, for instance, can support different hash functions. > > I would ask the group to state their preferences. > > I prefer option 2 but can live with option 1. > > Regards, > > _____________ > Roman Shpount > > On Fri, Apr 8, 2016 at 11:08 AM, Paul Kyzivat > wrote: > >> I don't have a horse in this race. I think those of you who do need to >> finish deciding what the rules are for multiple fingerprints, and then >> write the result into the draft update. Clearly it is ambiguous at the >> moment. >> >> Thanks, >> Paul >> >> On 4/7/16 5:37 PM, Cullen Jennings wrote: >> >>> >>> On Apr 7, 2016, at 11:20 AM, Roman Shpount >>> > wrote: >>>> >>>> You should check all the hashes you consider secure and if any one of >>>> them matches the DTLS association certificate, accept the media. >>>> >>> >>> +1 >>> >>> This allows us to do things like include hash for two servers even when >>> you re not sure which server will actually be used. >>> >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >>> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > --94eb2c055f681bd0c405315042ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Christer,

There is no indication what f= ingerprint applies to what certificate in SDP fingerprint attribute. The ru= le should be if connection is established a certificate which matches at le= ast one hash that you consider secure, the connection should be accepted. I= f you would make it more complicated, this will likely break backwards inte= rop or would require changes to fingerprint/DTLS/certificates.
Regards,

_____________
Roman Shpount
=

On Mon, Apr 25, 2016 at 9:38 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>
Hi,

I think option 1) does not support hash agility =E2=80=93 which is one= of the main reason from sending multiple fingerprints to begin with =E2=80= =93 as it assumes that the sender and receiver will support the same hash f= unctions.

Option 2) seems to be what Cullen also suggested: as long as there is = at least one fingerprint (calculated using a has function which the receive= r considers secure enough) that matches the DTLS association. So, in genera= l I support option 2).

However, we need to keep in mind that there may be fingerprints sent f= or multiple certificates. Do we need to mandate at least one match per cerf= ificate?

Regards,

Christer



From: mmusic <mmusic-bounces@ietf.org> = on behalf of Roman Shpount <roman@telurix.com>
Date: Friday 8 April 2016 at 22:14<= br> To: "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu= >
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] 4572 update: = forbid weak hashes?

I just wanted to re-iterate the question. We have two opti= ons:

1. If m=3D line has multiple fingerprints with hash functions X, Y, Z,= at least one fingerprint with each function must match DTLS association fo= r the media to be accepted. For example, if m=3D line has two fingerprints = with hash function SHA-1, and two with SHA-512, DTLS association certificate must match at least one SHA-1 and on= e SHA-512 fingerprint.

2. If m=3D line has multiple fingerprints with hash functions X, Y, Z,= at least one fingerprint with any hash function which is considered secure= enough must match DTLS association for the media to be accepted. For examp= le, if m=3D line has two fingerprints with hash function SHA-1, and two with SHA-512, DTLS association certifica= te must match one of either SHA-1 or SHA-512 fingerprints.

Option 1 has a benefit of being more secure since it provides the comb= ined secure of individual hash functions. It does put additional restrictio= ns how equipment can be combined into producing a single m=3D line. For ins= tance if fingerprints from two servers are combined into a single m=3D line and it is not known in advance which = one will be used, both servers will need to always support the same hash fu= nctions and be updated at the same time.

Option 2 is less secure since it is only as secure as the least secure= hash. On the other hand option 2 allows to be more flexible in how equipme= nt is combined to form the single m=3D line. Two servers in above example, = for instance, can support different hash functions.

I would ask the group to state their preferences.

I prefer option 2 but can live with option 1.=C2=A0

Regards,

_____________
Roman Shpount

On Fri, Apr 8, 2016 at 11:08 AM, Paul Kyzivat <pkyzivat@alu= m.mit.edu> wrote:
I don't have a horse in this race. I think those of you who do need to = finish deciding what the rules are for multiple fingerprints, and then writ= e the result into the draft update. Clearly it is ambiguous at the moment.<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

On 4/7/16 5:37 PM, Cullen Jennings wrote:

On Apr 7, 2016, at 11:20 AM, Roman Shpount <roman@telurix.com
<mailto:roman@telurix.com>> wrote:

You should check all the hashes you consider secure and if any one of
them matches the DTLS association certificate, accept the media.

+1

This allows us to do things like include hash for two servers even when
you re not sure which server will actually be used.




_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic


_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic

--94eb2c055f681bd0c405315042ea-- From nobody Mon Apr 25 11:39:02 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE67612D683 for ; Mon, 25 Apr 2016 11:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvAKMFq7-Fsm for ; Mon, 25 Apr 2016 11:37:46 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049A612D66E for ; Mon, 25 Apr 2016 11:37:16 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-9f-571e63da77c5 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id FD.9A.12516.AD36E175; Mon, 25 Apr 2016 20:37:15 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0248.002; Mon, 25 Apr 2016 20:37:14 +0200 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] 4572 update: forbid weak hashes? Thread-Index: AQHRkMlvyALEPXgXDkKRhXLaT8/AmJ9+gkOg///n5gCAACIUsP//4eqAgAB6NgCAASWpgIAARJyAgBqMZgD//+CxgAAMKyYw Date: Mon, 25 Apr 2016 18:37:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F7CD82@ESESSMB209.ericsson.se> References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F27D6E@ESESSMB209.ericsson.se> <4F76BA3A-A69A-473E-97DA-287E6E571324@iii.ca> <5707C985.5060809@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37F7CD82ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2J7iO7tZLlwg4YOFoupyx+zWKzYcIDV YsaFqcwOzB5/339g8liy5CeTx60pBQHMUVw2Kak5mWWpRfp2CVwZb37uZy9Yc4exYttMywbG I9cYuxg5OCQETCS+Tk3uYuQEMsUkLtxbz9bFyMUhJHCEUWJ762koZwmjxMx725lBGtgELCS6 /2mDNIgIqEr8/T6ZCcRmFvCVeLngC1iJsICZxLXjsRAl5hI/GxpZIOw8ic8dqxhBbBag1q7j a9lBbF6g1l27tjBCrHrMIrF09VawBKdAoMSkQ7fAbEag476fWgO1S1zi1pP5TBBHC0gs2XOe GcIWlXj5+B8rhK0ksWL7JUaI+nyJhsefWSGWCUqcnPmEZQKj6Cwko2YhKZuFpGwW0DvMApoS 63fpQ5QoSkzpfsgOYWtItM6Zy44svoCRfRWjaHFqcXFuupGxXmpRZnJxcX6eXl5qySZGYPwd 3PJbdwfj6teOhxgFOBiVeHgXcMqGC7EmlhVX5h5ilOBgVhLhXREnFy7Em5JYWZValB9fVJqT WnyIUZqDRUmcNyfyX5iQQHpiSWp2ampBahFMlomDU6qB0Xp/yCK3HbKr1238rs+y80S4/daF mUfkZuewz0j0X/bnC4OnscL5xPgNmmd/NehPZO4+9su057Y+3y7Gi7tsf6dG7o6SZ4+LX74q 913T12mhRafffbsYJOb3QKAl5Fm+4vtFk0PuPEperb4p69Pi9YEcNu/3O27vvmf/YV2V9mYx MenCHTOf2CixFGckGmoxFxUnAgDOhs66uwIAAA== Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 18:37:57 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37F7CD82ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5UaGVyZSBpcyBubyBpbmRpY2F0aW9uIHdoYXQgZmluZ2VycHJpbnQgYXBwbGllcyB0 byB3aGF0IGNlcnRpZmljYXRlIGluIFNEUCBmaW5nZXJwcmludCBhdHRyaWJ1dGUuID5UaGUgcnVs ZSBzaG91bGQgYmUgaWYgY29ubmVjdGlvbiBpcyBlc3RhYmxpc2hlZCBhIGNlcnRpZmljYXRlIHdo aWNoIG1hdGNoZXMgYXQgbGVhc3Qgb25lIGhhc2ggPnRoYXQgeW91IGNvbnNpZGVyIHNlY3VyZSwg dGhlIGNvbm5lY3Rpb24gc2hvdWxkIGJlIGFjY2VwdGVkLiBJZiB5b3Ugd291bGQgbWFrZSBpdCBt b3JlID5jb21wbGljYXRlZCwgdGhpcyB3aWxsIGxpa2VseSBicmVhayBiYWNrd2FyZHMgaW50ZXJv cCBvciB3b3VsZCByZXF1aXJlIGNoYW5nZXMgdG8gPmZpbmdlcnByaW50L0RUTFMvY2VydGlmaWNh dGVzLg0KDQpJIGRvbuKAmXQgd2FudCB0byBtYWtlIHRoaW5ncyBjb21wbGljYXRlZCDigJMgSSB3 YW50IHRvIGFncmVlIG9uIHNvbWV0aGluZywgdXBkYXRlIHRoZSBkcmFmdCBiYXNlZCBvbiB0aGF0 LCBhbmQgZ28gV0dMQyA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQpPbiBNb24s IEFwciAyNSwgMjAxNiBhdCA5OjM4IEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+ PiB3cm90ZToNCkhpLA0KDQpJIHRoaW5rIG9wdGlvbiAxKSBkb2VzIG5vdCBzdXBwb3J0IGhhc2gg YWdpbGl0eSDigJMgd2hpY2ggaXMgb25lIG9mIHRoZSBtYWluIHJlYXNvbiBmcm9tIHNlbmRpbmcg bXVsdGlwbGUgZmluZ2VycHJpbnRzIHRvIGJlZ2luIHdpdGgg4oCTIGFzIGl0IGFzc3VtZXMgdGhh dCB0aGUgc2VuZGVyIGFuZCByZWNlaXZlciB3aWxsIHN1cHBvcnQgdGhlIHNhbWUgaGFzaCBmdW5j dGlvbnMuDQoNCk9wdGlvbiAyKSBzZWVtcyB0byBiZSB3aGF0IEN1bGxlbiBhbHNvIHN1Z2dlc3Rl ZDogYXMgbG9uZyBhcyB0aGVyZSBpcyBhdCBsZWFzdCBvbmUgZmluZ2VycHJpbnQgKGNhbGN1bGF0 ZWQgdXNpbmcgYSBoYXMgZnVuY3Rpb24gd2hpY2ggdGhlIHJlY2VpdmVyIGNvbnNpZGVycyBzZWN1 cmUgZW5vdWdoKSB0aGF0IG1hdGNoZXMgdGhlIERUTFMgYXNzb2NpYXRpb24uIFNvLCBpbiBnZW5l cmFsIEkgc3VwcG9ydCBvcHRpb24gMikuDQoNCkhvd2V2ZXIsIHdlIG5lZWQgdG8ga2VlcCBpbiBt aW5kIHRoYXQgdGhlcmUgbWF5IGJlIGZpbmdlcnByaW50cyBzZW50IGZvciBtdWx0aXBsZSBjZXJ0 aWZpY2F0ZXMuIERvIHdlIG5lZWQgdG8gbWFuZGF0ZSBhdCBsZWFzdCBvbmUgbWF0Y2ggcGVyIGNl cmZpZmljYXRlPw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KRnJvbTogbW11c2ljIDxt bXVzaWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc+PiBv biBiZWhhbGYgb2YgUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFu QHRlbHVyaXguY29tPj4NCkRhdGU6IEZyaWRheSA4IEFwcmlsIDIwMTYgYXQgMjI6MTQNClRvOiAi cGt5eml2YXRAYWx1bS5taXQuZWR1PG1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+IiA8cGt5 eml2YXRAYWx1bS5taXQuZWR1PG1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+Pg0KQ2M6ICJt bXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4iIDxtbXVzaWNAaWV0Zi5vcmc8 bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW01NVVNJQ10gNDU3MiB1cGRh dGU6IGZvcmJpZCB3ZWFrIGhhc2hlcz8NCg0KSSBqdXN0IHdhbnRlZCB0byByZS1pdGVyYXRlIHRo ZSBxdWVzdGlvbi4gV2UgaGF2ZSB0d28gb3B0aW9uczoNCg0KMS4gSWYgbT0gbGluZSBoYXMgbXVs dGlwbGUgZmluZ2VycHJpbnRzIHdpdGggaGFzaCBmdW5jdGlvbnMgWCwgWSwgWiwgYXQgbGVhc3Qg b25lIGZpbmdlcnByaW50IHdpdGggZWFjaCBmdW5jdGlvbiBtdXN0IG1hdGNoIERUTFMgYXNzb2Np YXRpb24gZm9yIHRoZSBtZWRpYSB0byBiZSBhY2NlcHRlZC4gRm9yIGV4YW1wbGUsIGlmIG09IGxp bmUgaGFzIHR3byBmaW5nZXJwcmludHMgd2l0aCBoYXNoIGZ1bmN0aW9uIFNIQS0xLCBhbmQgdHdv IHdpdGggU0hBLTUxMiwgRFRMUyBhc3NvY2lhdGlvbiBjZXJ0aWZpY2F0ZSBtdXN0IG1hdGNoIGF0 IGxlYXN0IG9uZSBTSEEtMSBhbmQgb25lIFNIQS01MTIgZmluZ2VycHJpbnQuDQoNCjIuIElmIG09 IGxpbmUgaGFzIG11bHRpcGxlIGZpbmdlcnByaW50cyB3aXRoIGhhc2ggZnVuY3Rpb25zIFgsIFks IFosIGF0IGxlYXN0IG9uZSBmaW5nZXJwcmludCB3aXRoIGFueSBoYXNoIGZ1bmN0aW9uIHdoaWNo IGlzIGNvbnNpZGVyZWQgc2VjdXJlIGVub3VnaCBtdXN0IG1hdGNoIERUTFMgYXNzb2NpYXRpb24g Zm9yIHRoZSBtZWRpYSB0byBiZSBhY2NlcHRlZC4gRm9yIGV4YW1wbGUsIGlmIG09IGxpbmUgaGFz IHR3byBmaW5nZXJwcmludHMgd2l0aCBoYXNoIGZ1bmN0aW9uIFNIQS0xLCBhbmQgdHdvIHdpdGgg U0hBLTUxMiwgRFRMUyBhc3NvY2lhdGlvbiBjZXJ0aWZpY2F0ZSBtdXN0IG1hdGNoIG9uZSBvZiBl aXRoZXIgU0hBLTEgb3IgU0hBLTUxMiBmaW5nZXJwcmludHMuDQoNCk9wdGlvbiAxIGhhcyBhIGJl bmVmaXQgb2YgYmVpbmcgbW9yZSBzZWN1cmUgc2luY2UgaXQgcHJvdmlkZXMgdGhlIGNvbWJpbmVk IHNlY3VyZSBvZiBpbmRpdmlkdWFsIGhhc2ggZnVuY3Rpb25zLiBJdCBkb2VzIHB1dCBhZGRpdGlv bmFsIHJlc3RyaWN0aW9ucyBob3cgZXF1aXBtZW50IGNhbiBiZSBjb21iaW5lZCBpbnRvIHByb2R1 Y2luZyBhIHNpbmdsZSBtPSBsaW5lLiBGb3IgaW5zdGFuY2UgaWYgZmluZ2VycHJpbnRzIGZyb20g dHdvIHNlcnZlcnMgYXJlIGNvbWJpbmVkIGludG8gYSBzaW5nbGUgbT0gbGluZSBhbmQgaXQgaXMg bm90IGtub3duIGluIGFkdmFuY2Ugd2hpY2ggb25lIHdpbGwgYmUgdXNlZCwgYm90aCBzZXJ2ZXJz IHdpbGwgbmVlZCB0byBhbHdheXMgc3VwcG9ydCB0aGUgc2FtZSBoYXNoIGZ1bmN0aW9ucyBhbmQg YmUgdXBkYXRlZCBhdCB0aGUgc2FtZSB0aW1lLg0KDQpPcHRpb24gMiBpcyBsZXNzIHNlY3VyZSBz aW5jZSBpdCBpcyBvbmx5IGFzIHNlY3VyZSBhcyB0aGUgbGVhc3Qgc2VjdXJlIGhhc2guIE9uIHRo ZSBvdGhlciBoYW5kIG9wdGlvbiAyIGFsbG93cyB0byBiZSBtb3JlIGZsZXhpYmxlIGluIGhvdyBl cXVpcG1lbnQgaXMgY29tYmluZWQgdG8gZm9ybSB0aGUgc2luZ2xlIG09IGxpbmUuIFR3byBzZXJ2 ZXJzIGluIGFib3ZlIGV4YW1wbGUsIGZvciBpbnN0YW5jZSwgY2FuIHN1cHBvcnQgZGlmZmVyZW50 IGhhc2ggZnVuY3Rpb25zLg0KDQpJIHdvdWxkIGFzayB0aGUgZ3JvdXAgdG8gc3RhdGUgdGhlaXIg cHJlZmVyZW5jZXMuDQoNCkkgcHJlZmVyIG9wdGlvbiAyIGJ1dCBjYW4gbGl2ZSB3aXRoIG9wdGlv biAxLg0KDQpSZWdhcmRzLA0KDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCk9uIEZy aSwgQXByIDgsIDIwMTYgYXQgMTE6MDggQU0sIFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5t aXQuZWR1PG1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+PiB3cm90ZToNCkkgZG9uJ3QgaGF2 ZSBhIGhvcnNlIGluIHRoaXMgcmFjZS4gSSB0aGluayB0aG9zZSBvZiB5b3Ugd2hvIGRvIG5lZWQg dG8gZmluaXNoIGRlY2lkaW5nIHdoYXQgdGhlIHJ1bGVzIGFyZSBmb3IgbXVsdGlwbGUgZmluZ2Vy cHJpbnRzLCBhbmQgdGhlbiB3cml0ZSB0aGUgcmVzdWx0IGludG8gdGhlIGRyYWZ0IHVwZGF0ZS4g Q2xlYXJseSBpdCBpcyBhbWJpZ3VvdXMgYXQgdGhlIG1vbWVudC4NCg0KICAgICAgICBUaGFua3Ms DQogICAgICAgIFBhdWwNCg0KT24gNC83LzE2IDU6MzcgUE0sIEN1bGxlbiBKZW5uaW5ncyB3cm90 ZToNCg0KT24gQXByIDcsIDIwMTYsIGF0IDExOjIwIEFNLCBSb21hbiBTaHBvdW50IDxyb21hbkB0 ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+DQo8bWFpbHRvOnJvbWFuQHRlbHVy aXguY29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+PiB3cm90ZToNCg0KWW91IHNob3VsZCBj aGVjayBhbGwgdGhlIGhhc2hlcyB5b3UgY29uc2lkZXIgc2VjdXJlIGFuZCBpZiBhbnkgb25lIG9m DQp0aGVtIG1hdGNoZXMgdGhlIERUTFMgYXNzb2NpYXRpb24gY2VydGlmaWNhdGUsIGFjY2VwdCB0 aGUgbWVkaWEuDQoNCisxDQoNClRoaXMgYWxsb3dzIHVzIHRvIGRvIHRoaW5ncyBsaWtlIGluY2x1 ZGUgaGFzaCBmb3IgdHdvIHNlcnZlcnMgZXZlbiB3aGVuDQp5b3UgcmUgbm90IHN1cmUgd2hpY2gg c2VydmVyIHdpbGwgYWN0dWFsbHkgYmUgdXNlZC4NCg0KDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNp Y0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxt YWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tbXVzaWMNCg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B37F7CD82ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+VGhlcmUgaXMgbm8gaW5kaWNhdGlvbiB3aGF0IGZp bmdlcnByaW50IGFwcGxpZXMgdG8gd2hhdCBjZXJ0aWZpY2F0ZSBpbiBTRFAgZmluZ2VycHJpbnQg YXR0cmlidXRlLg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+VGhlIHJ1 bGUgc2hvdWxkIGJlIGlmIGNvbm5lY3Rpb24gaXMgZXN0YWJsaXNoZWQgYSBjZXJ0aWZpY2F0ZSB3 aGljaCBtYXRjaGVzIGF0IGxlYXN0IG9uZSBoYXNoDQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+Jmd0Ozwvc3Bhbj50aGF0IHlvdSBjb25zaWRlciBzZWN1cmUsIHRoZSBjb25uZWN0aW9uIHNo b3VsZCBiZSBhY2NlcHRlZC4gSWYgeW91IHdvdWxkIG1ha2UgaXQgbW9yZQ0KPHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+Y29tcGxpY2F0ZWQsIHRoaXMgd2lsbCBsaWtlbHkg YnJlYWsgYmFja3dhcmRzIGludGVyb3Agb3Igd291bGQgcmVxdWlyZSBjaGFuZ2VzIHRvDQo8c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5maW5nZXJwcmludC9EVExTL2NlcnRp ZmljYXRlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SSBkb27igJl0IHdhbnQgdG8gbWFrZSB0aGluZ3MgY29tcGxpY2F0ZWQg4oCTIEkgd2FudCB0byBh Z3JlZSBvbiBzb21ldGhpbmcsIHVwZGF0ZSB0aGUgZHJhZnQgYmFzZWQgb24gdGhhdCwgYW5kIGdv IFdHTEMgOik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2Fy ZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaHJpc3Rlcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBNb24sIEFwciAyNSwgMjAxNiBhdCA5OjM4IEFNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSB0aGluayBvcHRp b24gMSkgZG9lcyBub3Qgc3VwcG9ydCBoYXNoIGFnaWxpdHkg4oCTIHdoaWNoIGlzIG9uZSBvZiB0 aGUgbWFpbiByZWFzb24gZnJvbSBzZW5kaW5nIG11bHRpcGxlIGZpbmdlcnByaW50cyB0byBiZWdp biB3aXRoIOKAkyBhcyBpdCBhc3N1bWVzIHRoYXQgdGhlIHNlbmRlcg0KIGFuZCByZWNlaXZlciB3 aWxsIHN1cHBvcnQgdGhlIHNhbWUgaGFzaCBmdW5jdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk9wdGlvbiAy KSBzZWVtcyB0byBiZSB3aGF0IEN1bGxlbiBhbHNvIHN1Z2dlc3RlZDogYXMgbG9uZyBhcyB0aGVy ZSBpcyBhdCBsZWFzdCBvbmUgZmluZ2VycHJpbnQgKGNhbGN1bGF0ZWQgdXNpbmcgYSBoYXMgZnVu Y3Rpb24gd2hpY2ggdGhlIHJlY2VpdmVyIGNvbnNpZGVycyBzZWN1cmUNCiBlbm91Z2gpIHRoYXQg bWF0Y2hlcyB0aGUgRFRMUyBhc3NvY2lhdGlvbi4gU28sIGluIGdlbmVyYWwgSSBzdXBwb3J0IG9w dGlvbiAyKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+SG93ZXZlciwgd2UgbmVlZCB0byBrZWVwIGluIG1pbmQgdGhh dCB0aGVyZSBtYXkgYmUgZmluZ2VycHJpbnRzIHNlbnQgZm9yIG11bHRpcGxlIGNlcnRpZmljYXRl cy4gRG8gd2UgbmVlZCB0byBtYW5kYXRlIGF0IGxlYXN0IG9uZSBtYXRjaCBwZXIgY2VyZmlmaWNh dGU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkNocmlzdGVyPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+bW11c2ljICZsdDs8YSBocmVmPSJtYWls dG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWMtYm91bmNl c0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBSb21hbiBTaHBvdW50ICZsdDs8YSBocmVm PSJtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20iIHRhcmdldD0iX2JsYW5rIj5yb21hbkB0ZWx1cml4 LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSA4IEFwcmlsIDIwMTYgYXQgMjI6 MTQ8YnI+DQo8Yj5UbzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpwa3l6aXZhdEBhbHVtLm1p dC5lZHUiIHRhcmdldD0iX2JsYW5rIj5wa3l6aXZhdEBhbHVtLm1pdC5lZHU8L2E+JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+ cGt5eml2YXRAYWx1bS5taXQuZWR1PC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90OzxhIGhy ZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5v cmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+bW11c2ljQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6 IFtNTVVTSUNdIDQ1NzIgdXBkYXRlOiBmb3JiaWQgd2VhayBoYXNoZXM/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JIGp1c3Qgd2FudGVkIHRvIHJlLWl0ZXJhdGUgdGhl IHF1ZXN0aW9uLiBXZSBoYXZlIHR3byBvcHRpb25zOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4xLiBJZiBtPSBsaW5lIGhhcyBt dWx0aXBsZSBmaW5nZXJwcmludHMgd2l0aCBoYXNoIGZ1bmN0aW9ucyBYLCBZLCBaLCBhdCBsZWFz dCBvbmUgZmluZ2VycHJpbnQgd2l0aCBlYWNoIGZ1bmN0aW9uIG11c3QgbWF0Y2ggRFRMUyBhc3Nv Y2lhdGlvbiBmb3IgdGhlIG1lZGlhIHRvIGJlDQogYWNjZXB0ZWQuIEZvciBleGFtcGxlLCBpZiBt PSBsaW5lIGhhcyB0d28gZmluZ2VycHJpbnRzIHdpdGggaGFzaCBmdW5jdGlvbiBTSEEtMSwgYW5k IHR3byB3aXRoIFNIQS01MTIsIERUTFMgYXNzb2NpYXRpb24gY2VydGlmaWNhdGUgbXVzdCBtYXRj aCBhdCBsZWFzdCBvbmUgU0hBLTEgYW5kIG9uZSBTSEEtNTEyIGZpbmdlcnByaW50LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4yLiBJZiBtPSBsaW5lIGhhcyBtdWx0aXBsZSBmaW5nZXJwcmludHMgd2l0aCBoYXNoIGZ1 bmN0aW9ucyBYLCBZLCBaLCBhdCBsZWFzdCBvbmUgZmluZ2VycHJpbnQgd2l0aCBhbnkgaGFzaCBm dW5jdGlvbiB3aGljaCBpcyBjb25zaWRlcmVkIHNlY3VyZSBlbm91Z2ggbXVzdCBtYXRjaA0KIERU TFMgYXNzb2NpYXRpb24gZm9yIHRoZSBtZWRpYSB0byBiZSBhY2NlcHRlZC4gRm9yIGV4YW1wbGUs IGlmIG09IGxpbmUgaGFzIHR3byBmaW5nZXJwcmludHMgd2l0aCBoYXNoIGZ1bmN0aW9uIFNIQS0x LCBhbmQgdHdvIHdpdGggU0hBLTUxMiwgRFRMUyBhc3NvY2lhdGlvbiBjZXJ0aWZpY2F0ZSBtdXN0 IG1hdGNoIG9uZSBvZiBlaXRoZXIgU0hBLTEgb3IgU0hBLTUxMiBmaW5nZXJwcmludHMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPk9wdGlvbiAxIGhhcyBhIGJlbmVmaXQgb2YgYmVpbmcgbW9yZSBzZWN1cmUgc2luY2Ug aXQgcHJvdmlkZXMgdGhlIGNvbWJpbmVkIHNlY3VyZSBvZiBpbmRpdmlkdWFsIGhhc2ggZnVuY3Rp b25zLiBJdCBkb2VzIHB1dCBhZGRpdGlvbmFsIHJlc3RyaWN0aW9ucyBob3cgZXF1aXBtZW50DQog Y2FuIGJlIGNvbWJpbmVkIGludG8gcHJvZHVjaW5nIGEgc2luZ2xlIG09IGxpbmUuIEZvciBpbnN0 YW5jZSBpZiBmaW5nZXJwcmludHMgZnJvbSB0d28gc2VydmVycyBhcmUgY29tYmluZWQgaW50byBh IHNpbmdsZSBtPSBsaW5lIGFuZCBpdCBpcyBub3Qga25vd24gaW4gYWR2YW5jZSB3aGljaCBvbmUg d2lsbCBiZSB1c2VkLCBib3RoIHNlcnZlcnMgd2lsbCBuZWVkIHRvIGFsd2F5cyBzdXBwb3J0IHRo ZSBzYW1lIGhhc2ggZnVuY3Rpb25zIGFuZCBiZQ0KIHVwZGF0ZWQgYXQgdGhlIHNhbWUgdGltZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+T3B0aW9uIDIgaXMgbGVzcyBzZWN1cmUgc2luY2UgaXQgaXMgb25seSBhcyBz ZWN1cmUgYXMgdGhlIGxlYXN0IHNlY3VyZSBoYXNoLiBPbiB0aGUgb3RoZXIgaGFuZCBvcHRpb24g MiBhbGxvd3MgdG8gYmUgbW9yZSBmbGV4aWJsZSBpbiBob3cgZXF1aXBtZW50IGlzIGNvbWJpbmVk DQogdG8gZm9ybSB0aGUgc2luZ2xlIG09IGxpbmUuIFR3byBzZXJ2ZXJzIGluIGFib3ZlIGV4YW1w bGUsIGZvciBpbnN0YW5jZSwgY2FuIHN1cHBvcnQgZGlmZmVyZW50IGhhc2ggZnVuY3Rpb25zLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5JIHdvdWxkIGFzayB0aGUgZ3JvdXAgdG8gc3RhdGUgdGhlaXIgcHJlZmVyZW5j ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPkkgcHJlZmVyIG9wdGlvbiAyIGJ1dCBjYW4gbGl2ZSB3aXRoIG9wdGlv biAxLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5PbiBGcmksIEFwciA4 LCAyMDE2IGF0IDExOjA4IEFNLCBQYXVsIEt5eml2YXQgJmx0OzxhIGhyZWY9Im1haWx0bzpwa3l6 aXZhdEBhbHVtLm1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5wa3l6aXZhdEBhbHVtLm1pdC5lZHU8 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JIGRvbid0IGhhdmUg YSBob3JzZSBpbiB0aGlzIHJhY2UuIEkgdGhpbmsgdGhvc2Ugb2YgeW91IHdobyBkbyBuZWVkIHRv IGZpbmlzaCBkZWNpZGluZyB3aGF0IHRoZSBydWxlcyBhcmUgZm9yIG11bHRpcGxlIGZpbmdlcnBy aW50cywgYW5kIHRoZW4gd3JpdGUgdGhlIHJlc3VsdCBpbnRvDQogdGhlIGRyYWZ0IHVwZGF0ZS4g Q2xlYXJseSBpdCBpcyBhbWJpZ3VvdXMgYXQgdGhlIG1vbWVudC48YnI+DQo8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhhbmtzLDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBQYXVsPGJyPg0KPGJyPg0KT24gNC83LzE2IDU6MzcgUE0sIEN1bGxlbiBKZW5uaW5ncyB3 cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5PbiBBcHIgNywgMjAxNiwgYXQgMTE6MjAgQU0sIFJvbWFuIFNocG91bnQg Jmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJv bWFuQHRlbHVyaXguY29tPC9hPjxicj4NCiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnJvbWFu QHRlbHVyaXguY29tIiB0YXJnZXQ9Il9ibGFuayI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0OyZn dDsgd3JvdGU6PGJyPg0KPGJyPg0KWW91IHNob3VsZCBjaGVjayBhbGwgdGhlIGhhc2hlcyB5b3Ug Y29uc2lkZXIgc2VjdXJlIGFuZCBpZiBhbnkgb25lIG9mPGJyPg0KdGhlbSBtYXRjaGVzIHRoZSBE VExTIGFzc29jaWF0aW9uIGNlcnRpZmljYXRlLCBhY2NlcHQgdGhlIG1lZGlhLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48YnI+DQom IzQzOzE8YnI+DQo8YnI+DQpUaGlzIGFsbG93cyB1cyB0byBkbyB0aGluZ3MgbGlrZSBpbmNsdWRl IGhhc2ggZm9yIHR3byBzZXJ2ZXJzIGV2ZW4gd2hlbjxicj4NCnlvdSByZSBub3Qgc3VyZSB3aGlj aCBzZXJ2ZXIgd2lsbCBhY3R1YWxseSBiZSB1c2VkLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K bW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptbXVzaWMgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1t dXNpY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21tdXNpYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B37F7CD82ESESSMB209erics_-- From nobody Mon Apr 25 11:53:25 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8686312B041 for ; Mon, 25 Apr 2016 11:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7w_ceTmZvS9 for ; Mon, 25 Apr 2016 11:53:21 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E4712D601 for ; Mon, 25 Apr 2016 11:53:20 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-60-571e679f65b9 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 21.4E.12926.F976E175; Mon, 25 Apr 2016 20:53:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0248.002; Mon, 25 Apr 2016 20:53:18 +0200 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] DTLS-SDP: "actress" to always trigger new DTLS association? Thread-Index: AQHRnvJFE9/VC7yRi0qI3xYwkFAAip+aoFsAgABoMIA= Date: Mon, 25 Apr 2016 18:53:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F7CE6F@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37F7CE6FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7q+78dLlwg6dLJCymLn/MYjHjwlRm ByaPJUt+MnncmlIQwBTFZZOSmpNZllqkb5fAldHy6DZbwa5JjBU3375gbGA80sfYxcjJISFg InH3+UIWCFtM4sK99WxdjFwcQgJHGCX6vx5hh3CWMEo83LkEyOHgYBOwkOj+pw3SICKgKvH3 +2QmkDCzgLrE1cVBIGFhgWCJhe962CFKQiQ+7FnNBGFbSRycdYsZpJwFqPXCDAcQk1fAV+LR ZneIRY2MEi8WHWQFiXMKBErcX14F0skIdNn3U2vApjALiEvcejKfCeJiAYkle84zQ9iiEi8f /2OFsJUkVmy/xAhRny/x8+w5sBpeAUGJkzOfsExgFJ2FZNQsJGWzkJTNAvtLU2L9Ln2IEkWJ Kd0P2SFsDYnWOXPZkcUXMLKvYhQtTi1Oyk03MtZLLcpMLi7Oz9PLSy3ZxAiMtINbfqvuYLz8 xvEQowAHoxIP7wJO2XAh1sSy4srcQ4wSHMxKIrwqyXLhQrwpiZVVqUX58UWlOanFhxilOViU xHmzI/+FCQmkJ5akZqemFqQWwWSZODilGhgz3MonFKUGvLirdflcvMKnT7dPLn4Yf9T6oGbz r10aXWccS+/XNjeyHfD2fzJN77fuHpEX5VyBS1IYt224mP+sm41935y4D1bJv+T/Gn3+G3HQ KDve7e/9e6zLhRo/JLTtWBc+af7XFUsfb95p5J7zoVRdSNvvrsyL384LchQOTb/XsjK5wkZD iaU4I9FQi7moOBEALOS8ErACAAA= Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-SDP: "actress" to always trigger new DTLS association? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 18:53:23 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37F7CE6FESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5UaGlzIGlzIGEgdmVyeSBjb21tb24gdG9waWMgb2ZyIGNvbmZ1c2lvbi4gU2VlIGh0 dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWItd2cvanNlcC9pc3N1ZXMvNzIgZm9yIGEgc2ltaWxhciBk aXNjdXNzaW9uLg0KPg0KPlRoZSB3aG9sZSBpc3N1ZSBpcyB0aGF0IGFuc3dlcmVyIGNhbiBpbml0 aWF0ZSBhIG5ldyBEVExTIGFzc29jaWF0aW9uLiBTbyBpZiBvZmZlcmVyIGdlbmVyYXRlcyBhbiBv ZmZlciB0aGF0IGFsbG93cyBhbg0KPmFuc3dlcmVyIHN0YXJ0IGEgbmV3IERUTFMgYXNzb2NpYXRp b24sIGkuZS4gYW4gb2ZmZXIgd2l0aG91dCBJQ0Ugb3Igb2ZmZXIgd2l0aCBJQ0UgcmVzdGFydCwg dGhpcyBvZmZlciBzaG91bGQgaGF2ZQ0KPmFjdHBhc3MuIFdpdGhvdXQgYWN0cGFzcyByb2xlLCB0 aGUgYW5zd2VyZXIgd2hlbiBzdGFydGluZyBhIG5ldyBEVExTIGFzc29jaWF0aW9uIHdvdWxkIGhh dmUgdG8gcmV1c2UgdGhlIG9sZA0KPm5lZ290aWF0ZWQgcm9sZSwgd2hpY2gsIGlmIGFuc3dlcmVy IHdhcyBwcmV2aW91c2x5IHBhc3NpdmUsIGNhbiBzbG93IGRvd24gdGhlIGFzc29jaWF0aW9uIHNl dHVwIGJ5IGhhbGYgYSByb3VuZCB0cmlwLg0KDQpJIGFncmVlLg0KDQpNeSBxdWVzdGlvbiB3YXMg d2hldGhlciB0aGVyZSBpcyBhIGNhc2Ugd2hlcmUgb25lIHdvdWxkIG9mZmVyIOKAnGFjdHBhc3Pi gJ0sIGFuZCBhIG5ldyBEVExTIGFzc29jaWF0aW9uIHdvdWxkIE5PVCBiZSBjcmVhdGVkLg0KDQoN Cj5TbywgYmFzaWMgcnVsZXMgc2hvdWxkIGJlOg0KPjEuIERvIG5vdCBjaGFuZ2UgZmluZ2VycHJp bnRzL2Fzc29jaWF0aW9uLWlkIHVubGVzcyB5b3Ugd2FudCB0byBzZXR1cCBhIG5ldyBEVExTIGFz c29jaWF0aW9uLg0KPjIuIFNldCB0aGUgc2V0dXAgcm9sZSB0byBhY3RwYXNzIGlmIGFuc3dlcmVy IE1BWSBpbml0aWF0ZSBhIG5ldyBEVExTIGFzc29jaWF0aW9uDQo+My4gR2V0dGluZyBhIHNldHVw IHJvbGUgYWN0cGFzcyBpcyBub3QgZW5vdWdoIHRvIHN0YXJ0IGEgbmV3IERUTFMgYXNzb2NpYXRp b24uIENoYW5nZSBvZiBuZWdvdGlhdGVkIHJvbGUsIGkuZS4gY2hhbmdlIG9mIGFuc3dlcmVyJ3Mg c2V0dXAgcm9sZSwgaXMgbmVjZXNzYXJ5IGFzIGEgY29uZGl0aW9uIGZvciBzZXR0aW5nIHVwIG5l dyA+RFRMUyBhc3NvY2lhdGlvbi4NCg0KU28sIGlmIEkgb2ZmZXIg4oCcYWN0cGFzc+KAnSwgYnV0 IEkgZG8gTk9UIGNoYW5nZSB0aGUgZmluZ2VycHJpbnQvZHRscy1hc3NvY2lhdGlvbi1pZCwgaXQg aXMgc3RpbGwgb2sgZm9yIHRoZSBhbnN3ZXJlciB0byBjaGFuZ2UgdGhlIHNldHVwIHJvbGUgaW4g dGhlIGFuc3dlciAocmVhZDogY3JlYXRlIGEgbmV3IERUTFMgYXNzb2NpYXRpb24pPw0KDQpJIHRo b3VnaHQgeW91IGVhcmxpZXIgc2FpZCB0aGF0IHRoZSBmaW5nZXJwcmludC9kdGxzLWFzc29jaWF0 aW9uLWlkIGNvbWJpbmF0aW9uIG11c3QgY2hhbmdlIHdoZW4gYSBuZXcgRFRMUyBhc3NvY2lhdGlv biBpcyBjcmVhdGVkLCBidXQgaW4gdGhpcyBleGFtcGxlIHRoZSBvZmZlcmVyIHdpbGwgbm90IGNo YW5nZSB0aGUgY29tYmluYXRpb24uDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCg0K T24gTW9uLCBBcHIgMjUsIDIwMTYgYXQgODo1OSBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPj4gd3JvdGU6DQpIaSwNCg0KQXNzdW1lIHRoYXQgQWxpY2UgYW5kIEJvYiBoYXZlIG5l Z290aWF0ZWQgYSBEVExTIGFzc29jaWF0aW9uLiBBbGljZSBoYXMgdGhlIOKAnGFjdGl2ZeKAnSBy b2xlLCBhbmQgQm9iIGhhcyB0aGUg4oCccGFzc2l2ZeKAnSByb2xlLg0KDQpOb3csIGlmIEFsaWNl IHNlbmRzIGEgbmV3IG9mZmVyLCB3aXRoIOKAnHBhc3NpdmXigJ0sIHRoZSByb2xlcyB3aWxsIGNo YW5nZSBhbmQgdGhlIERUTFMgYXNzb2NpYXRpb24gd2lsbCBoYXZlIHRvIGJlIHJlLWVzdGFibGlz aGVkLg0KDQpJZiBBbGljZSBpbiB0aGUgbmV3IG9mZmVyIHNlbmRzIOKAnGFjdHBhc3PigJ0sIGl0 IGlzIHlldCBub3Qga25vd24gd2hldGhlciB0aGUgcm9sZXMgd2lsbCBjaGFuZ2UuDQoNCkhvd2V2 ZXIsIGFzIHRoZSByb2xlcyBNQVkgY2hhbmdlLCBpdCBoYXMgYmVlbiBzdWdnZXN0ZWQgdGhhdCB0 aGUgZmluZ2VycHJpbnQvZHRscy1hc3NvY2F0aW9uLWlkIGNvbWJpbmF0aW9uIG5lZWRzIHRvIGJl IHVwZGF0ZWQgaW4gdGhlIG9mZmVyIOKAkyB3aGljaCBieSBpdHNlbGYgcmVxdWlyZXMgYSBuZXcg RFRMUyBhc3NvY2lhdGlvbiA6KQ0KDQpNWSBRVUVTVElPTjogSXMgdGhlcmUgYSBjYXNlIGZvciBz ZW5kaW5nIOKAnGFjdHBhc3PigJ0gd2l0aG91dCB0aGUgaW50ZW50aW9uIG9mIGVzdGFibGlzaGlu ZyBhIG5ldyBEVExTIGFzc29jaWF0aW9uIOKAkyBubyBtYXR0ZXIgaWYgdGhlIHJvbGVzIGNoYW5n ZSBvciBub3Q/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QN Cm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0K --_000_7594FB04B1934943A5C02806D1A2204B37F7CE6FESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtUaGlzIGlzIGEgdmVyeSBj b21tb24gdG9waWMgb2ZyIGNvbmZ1c2lvbi4gU2VlJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9naXRo dWIuY29tL3J0Y3dlYi13Zy9qc2VwL2lzc3Vlcy83MiI+aHR0cHM6Ly9naXRodWIuY29tL3J0Y3dl Yi13Zy9qc2VwL2lzc3Vlcy83MjwvYT4gZm9yIGEgc2ltaWxhciBkaXNjdXNzaW9uLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O1Ro ZSB3aG9sZSBpc3N1ZSBpcyB0aGF0IGFuc3dlcmVyIGNhbiBpbml0aWF0ZSBhIG5ldyBEVExTIGFz c29jaWF0aW9uLiBTbyBpZiBvZmZlcmVyIGdlbmVyYXRlcyBhbiBvZmZlciB0aGF0IGFsbG93cyBh bjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m Z3Q7PC9zcGFuPmFuc3dlcmVyIHN0YXJ0IGEgbmV3IERUTFMgYXNzb2NpYXRpb24sIGkuZS4gYW4g b2ZmZXIgd2l0aG91dCBJQ0Ugb3Igb2ZmZXIgd2l0aCBJQ0UgcmVzdGFydCwgdGhpcyBvZmZlciBz aG91bGQgaGF2ZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZndDs8L3NwYW4+YWN0cGFzcy4gV2l0aG91dCBhY3RwYXNzIHJvbGUsIHRoZSBh bnN3ZXJlciB3aGVuIHN0YXJ0aW5nIGEgbmV3IERUTFMgYXNzb2NpYXRpb24gd291bGQgaGF2ZSB0 byByZXVzZSB0aGUgb2xkDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj5uZWdvdGlhdGVkIHJvbGUsIHdoaWNoLCBpZiBhbnN3 ZXJlciB3YXMgcHJldmlvdXNseSBwYXNzaXZlLCBjYW4gc2xvdyBkb3duIHRoZSBhc3NvY2lhdGlv biBzZXR1cCBieSBoYWxmIGEgcm91bmQgdHJpcC48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGFn cmVlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5NeSBxdWVzdGlvbiB3YXMgd2hldGhlciB0aGVyZSBpcyBhIGNh c2Ugd2hlcmUgb25lIHdvdWxkIG9mZmVyIOKAnGFjdHBhc3PigJ0sIGFuZCBhIG5ldyBEVExTIGFz c29jaWF0aW9uIHdvdWxkIE5PVCBiZSBjcmVhdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m Z3Q7U28sIGJhc2ljIHJ1bGVzIHNob3VsZCBiZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsxLiBEbyBub3QgY2hhbmdlIGZpbmdlcnByaW50 cy9hc3NvY2lhdGlvbi1pZCB1bmxlc3MgeW91IHdhbnQgdG8gc2V0dXAgYSBuZXcgRFRMUyBhc3Nv Y2lhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZndDsyLiBTZXQgdGhlIHNldHVwIHJvbGUgdG8gYWN0cGFzcyBpZiBhbnN3ZXJlciBNQVkg aW5pdGlhdGUgYSBuZXcgRFRMUyBhc3NvY2lhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzMuIEdldHRpbmcgYSBzZXR1cCByb2xlIGFj dHBhc3MgaXMgbm90IGVub3VnaCB0byBzdGFydCBhIG5ldyBEVExTIGFzc29jaWF0aW9uLiBDaGFu Z2Ugb2YgbmVnb3RpYXRlZCByb2xlLCBpLmUuIGNoYW5nZSBvZiBhbnN3ZXJlcidzIHNldHVwIHJv bGUsIGlzIG5lY2Vzc2FyeSBhcyBhIGNvbmRpdGlvbiBmb3Igc2V0dGluZyB1cCBuZXcgJmd0O0RU TFMgYXNzb2NpYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+U28sIGlmIEkgb2ZmZXIg4oCcYWN0cGFzc+KAnSwgYnV0IEkgZG8gTk9U IGNoYW5nZSB0aGUgZmluZ2VycHJpbnQvZHRscy1hc3NvY2lhdGlvbi1pZCwgaXQgaXMgc3RpbGwg b2sgZm9yIHRoZSBhbnN3ZXJlciB0byBjaGFuZ2UgdGhlIHNldHVwIHJvbGUgaW4gdGhlIGFuc3dl ciAocmVhZDogY3JlYXRlIGEgbmV3DQogRFRMUyBhc3NvY2lhdGlvbik/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkkgdGhvdWdodCB5b3UgZWFybGllciBzYWlkIHRoYXQgdGhlIGZpbmdlcnByaW50L2R0bHMtYXNz b2NpYXRpb24taWQgY29tYmluYXRpb24gbXVzdCBjaGFuZ2Ugd2hlbiBhIG5ldyBEVExTIGFzc29j aWF0aW9uIGlzIGNyZWF0ZWQsIGJ1dCBpbiB0aGlzIGV4YW1wbGUgdGhlIG9mZmVyZXIgd2lsbCBu b3QNCiBjaGFuZ2UgdGhlIGNvbWJpbmF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBNb24sIEFwciAyNSwgMjAxNiBhdCA4OjU5IEFNLCBDaHJpc3RlciBIb2xtYmVy ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5IaSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+QXNz dW1lIHRoYXQgQWxpY2UgYW5kIEJvYiBoYXZlIG5lZ290aWF0ZWQgYSBEVExTIGFzc29jaWF0aW9u LiBBbGljZSBoYXMgdGhlIOKAnGFjdGl2ZeKAnSByb2xlLCBhbmQgQm9iIGhhcyB0aGUg4oCccGFz c2l2ZeKAnSByb2xlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Ob3csIGlmIEFsaWNlIHNlbmRzIGEgbmV3IG9mZmVy LCB3aXRoIOKAnHBhc3NpdmXigJ0sIHRoZSByb2xlcyB3aWxsIGNoYW5nZSBhbmQgdGhlIERUTFMg YXNzb2NpYXRpb24gd2lsbCBoYXZlIHRvIGJlIHJlLWVzdGFibGlzaGVkLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5J ZiBBbGljZSBpbiB0aGUgbmV3IG9mZmVyIHNlbmRzIOKAnGFjdHBhc3PigJ0sIGl0IGlzIHlldCBu b3Qga25vd24gd2hldGhlciB0aGUgcm9sZXMgd2lsbCBjaGFuZ2UuJm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si Pkhvd2V2ZXIsIGFzIHRoZSByb2xlcyBNQVkgY2hhbmdlLCBpdCBoYXMgYmVlbiBzdWdnZXN0ZWQg dGhhdCB0aGUgZmluZ2VycHJpbnQvZHRscy1hc3NvY2F0aW9uLWlkIGNvbWJpbmF0aW9uIG5lZWRz IHRvIGJlIHVwZGF0ZWQgaW4gdGhlIG9mZmVyIOKAkyB3aGljaCBieSBpdHNlbGYgcmVxdWlyZXMN CiBhIG5ldyBEVExTIGFzc29jaWF0aW9uIDopPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk1ZIFFVRVNUSU9OOiBJcyB0 aGVyZSBhIGNhc2UgZm9yIHNlbmRpbmcg4oCcYWN0cGFzc+KAnSB3aXRob3V0IHRoZSBpbnRlbnRp b24gb2YgZXN0YWJsaXNoaW5nIGEgbmV3IERUTFMgYXNzb2NpYXRpb24g4oCTIG5vIG1hdHRlciBp ZiB0aGUgcm9sZXMgY2hhbmdlIG9yIG5vdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+UmVnYXJkcyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciPm1tdXNpY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B37F7CE6FESESSMB209erics_-- From nobody Mon Apr 25 12:15:37 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA6012D6AB for ; Mon, 25 Apr 2016 12:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 afNSSqAbdXVg for ; Mon, 25 Apr 2016 12:15:34 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40B1012D6B0 for ; Mon, 25 Apr 2016 12:15:22 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id u185so194447247iod.3 for ; Mon, 25 Apr 2016 12:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=avaTeVfjRVXe/xPyKuP6RSl43iIUBTCRC2WDhsfAbXA=; b=KDcAYVKum3ttao0wkerkpqe4WD3aHkWY4AsfxoZrvpB5ljF1+34gfthtCGIAO5GryK YmWTzh9kd22sABqy8qLGpUf8x3aEjvgTe1oW6LBwR+Q/GA2Djc8RvxvU/PpqUyD85mgI 0aUfJ8cTb8Mhsmr96+6bgVnTkU/1IY3ZjrZWdBx3UMjxujihgpB5z5Fc/lGBZ93yBjt8 kJ73GPLvoblllfCk4xwGJEXFdzOTMxpLiINbsUjnEaXwibupByKi4gTjn1c0IqZw5hgC gVVs/i54KvRSWstYhF5fSVkBqwvQzjNofIOxkufv1sQMzY3zIceN2iwZnOwfotfe3OwH DdfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=avaTeVfjRVXe/xPyKuP6RSl43iIUBTCRC2WDhsfAbXA=; b=EbjNrlvUxQ2IEbjjEk7gjy6NhpHRfP0HGi5byH3xjcP8biLBP3K+/t4qBQ8fXVrSU6 AL+wxFAl3ofmRenfqY0evgCdcvAMAeerDp3PI445IxB4X4Fn87C30brUFiYzLMkSNXwm w7VHAJPt4MIC96P/6WqlQT16Ef8tzaE+OAx+r7wXY8Ylm3B8JAGZpXMPKnxfhIGkik5N EzdfY32/XBqkiEsqixobrci9cIsQsCsrXWJNFQgBcBumXkVp07SCGcJeRS8jyZfUmBVM 7bbUwIqlfRu6r+Eoi9iyBt1KgluXy44smGdBvd//wNObZD//1Ewpov4I7XNBrJv6cz7V 9Vgg== X-Gm-Message-State: AOPr4FWP0KldUk43L9olt5EqYNSrtFWQ4x7ByhtKkgWY9SF5rdRfwnCPXIA79Odd7ZmH7Q== X-Received: by 10.107.175.104 with SMTP id y101mr42037332ioe.113.1461611721399; Mon, 25 Apr 2016 12:15:21 -0700 (PDT) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com. [209.85.213.176]) by smtp.gmail.com with ESMTPSA id r81sm10299219ioe.36.2016.04.25.12.15.20 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2016 12:15:20 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id bi2so75843576igb.0 for ; Mon, 25 Apr 2016 12:15:20 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.119.67 with SMTP id ks3mr9708180igb.78.1461611720403; Mon, 25 Apr 2016 12:15:20 -0700 (PDT) Received: by 10.36.144.69 with HTTP; Mon, 25 Apr 2016 12:15:20 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F7CE6F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37F7CE6F@ESESSMB209.ericsson.se> Date: Mon, 25 Apr 2016 15:15:20 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e011847f6651181053153ff35 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-SDP: "actress" to always trigger new DTLS association? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 19:15:36 -0000 --089e011847f6651181053153ff35 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Apr 25, 2016 at 2:53 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > My question was whether there is a case where one would offer =E2=80=9Cac= tpass=E2=80=9D, > and a new DTLS association would NOT be created. > There are a lot of use cases when offerer does not create a new DTLS association but would still want to allow the answerer to create one. 1. One example would be creating an offer in response to offerless INVITE. Offerer does not know if this offer will be sent to the same end point or to a new one. So it would create an offer with existing fingerprints and association id, but will put actpass setup role to allow answerer to create a new association. 2. Another common example is when different media resources are managed by the same signaling agent. When offerer send an offer the for instance adds video, signaling agent might send this offer to a different media resource which might cause a new DTLS association to be created. 3. Yet another example are SBCs that bridge DTLS-SRTP with non DTLS network. When such SBC receives an offer with the same transport/DTLS parameters it sends an offer on the non DTLS side using an existing transport. If it gets an answer on non DTLS side with the same remote transport, it sends an answer with an existing transport on DTLS side. If it gets an answer with the new remote transport on non DTLS side, it allocates a new transport on DTLS side and sends an answer that uses new transport and creates a new DTLS association. This way anything received on the old transport on DTLS side is sent to the old transport on non DTLS side and anything received on the new transport on DTLS side is sent to a new transport on non DTLS side. > I thought you earlier said that the fingerprint/dtls-association-id > combination must change when a new DTLS association is created, but in th= is > example the offerer will not change the combination. > > > Yes, for new implementation fingerprints/dtls-association-id must change for ONE OF THE SIDES. So, offerer might keep the the same fingerprint/dtls-association-id, but if answerer changes them, new DTLS association will be created. I would like to disallow changing just the role by the answerer for anything new, but for legacy interop creating a new association on just the role change needs to be supported (even though I do not think anybody does this). Regards, _____________ Roman Shpount --089e011847f6651181053153ff35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 25, 2016 at 2:53 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

My question was whether there is a case where one would offer =E2= =80=9Cactpass=E2=80=9D, and a new DTLS association would NOT be created.


There are a lot of use= cases when offerer does not create a new DTLS association but would still = want to allow the answerer to create one.

1. One e= xample would be creating an offer in response to offerless INVITE. Offerer = does not know if this offer will be sent to the same end point or to a new = one. So it would create an offer with existing fingerprints and association= id, but will put actpass setup role to allow answerer to create a new asso= ciation.=C2=A0

2. Another common example is when d= ifferent media resources are managed by the same signaling agent. When offe= rer send an offer the for instance adds video, signaling agent might send t= his offer to a different media resource which might cause a new DTLS associ= ation to be created.=C2=A0

3. Yet another example = are SBCs that bridge DTLS-SRTP with non DTLS network. When such SBC receive= s an offer with the same transport/DTLS parameters it sends an offer on the= non DTLS side using an existing transport. If it gets an answer on non DTL= S side with the same remote transport, it sends an answer with an existing = transport on DTLS side. If it gets an answer with the new remote transport = on non DTLS side, it allocates a new transport on DTLS side and sends an an= swer that uses new transport and creates a new DTLS association. This way a= nything received on the old transport on DTLS side is sent to the old trans= port on non DTLS side and anything received on the new transport on DTLS si= de is sent to a new transport on non DTLS side.
=C2=A0

I thought you earlier said that the fingerprint/dtls-association-= id combination must change when a new DTLS association is created, but in t= his example the offerer will not change the combination.


Yes, for new implementation fingerprints/dtls-association-id m= ust change for ONE OF THE SIDES. So, offerer might keep the the same finger= print/dtls-association-id, but if answerer changes them, new DTLS associati= on will be created. I would like to disallow changing just the role by the = answerer for anything new, but for legacy interop creating a new associatio= n on just the role change needs to be supported (even though I do not think= anybody does this).

Regards,
_____________
Roman Shpount
=C2=A0<= /div>
--089e011847f6651181053153ff35-- From nobody Mon Apr 25 12:18:35 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E013B12D680 for ; Mon, 25 Apr 2016 12:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 KQMxoStqL15U for ; Mon, 25 Apr 2016 12:18:32 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9602E12D537 for ; Mon, 25 Apr 2016 12:18:32 -0700 (PDT) Received: by mail-ig0-x231.google.com with SMTP id bi2so75932122igb.0 for ; Mon, 25 Apr 2016 12:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=DNfSm22J/cyUxTG9QHPuAG49EVYpE0luiPnoI3JuUsk=; b=qUXMO+9VJabBNH6kktw+lDeo71m1KIvUg8H9I/ZWk2NoDTa+8YnImh0QnOld4Kxakw LF93Rvkq7Ions59VOSPKX9QhwTxLmObTmziCih4t8sObXP3ngBAnZoYGwtnBR6MZIPvt hcnAkvmdBE71Lcl0nhHENnsms+238HHBRX2VuHmi/QeR+iCHTDtnYVdFb8iVPgC0dwPj FfE9AN0OAJpo2pJhkmHZ6UWPIqfa8aKF+g8xCbr0wEgA6LzFW851IH5QsQyYw7uvwkiq aucOckrk78dqzak99fSHK8ZHxEK+h/7y0GGQpGcQk4jies28kawe906m3cpXwKfuOoDm hm+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=DNfSm22J/cyUxTG9QHPuAG49EVYpE0luiPnoI3JuUsk=; b=i7TGJ9YULn4irMlXdBHSKIvjmpiLLNcZZyJVKGB0DjPvK1wLP9dCRtzoGFFPLSaICi TRd7PK3YiJOogBW8oDf5VaOJTxMu8ZOlSVpbwRXFDAk0cQAHYnLwmFLT/htfvRZvBM/T iXoc/OUEAW+fXRxa74GB51F+nvzEii6hOU/WB8FqSQRsQmPzNLU8w2wFn7+zQb7x9jMK gkHFHrT4CdaX58gWoO89pPsaNye4D4KKYV7LTNiwQjG5xtuXNArDFFafkrOT9l20varE wMTNci03VXjyUFyqtcRLAd2OUH8ay4WV+rGSbd27PNIQ6io4cijZYYX0bt1dSX83RYQq yVjg== X-Gm-Message-State: AOPr4FWdh3OJDTDnAoYdWW/WfJ4FziBRDO+5NhliDt3xQ1jMHvNHMxb6vPC0Q/0oJyWctw== X-Received: by 10.50.171.66 with SMTP id as2mr14380466igc.57.1461611911830; Mon, 25 Apr 2016 12:18:31 -0700 (PDT) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com. [209.85.213.177]) by smtp.gmail.com with ESMTPSA id 90sm11948106ior.21.2016.04.25.12.18.31 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2016 12:18:31 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id u5so5003864igk.1 for ; Mon, 25 Apr 2016 12:18:31 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.233.40 with SMTP id tt8mr14944990igc.78.1461611911000; Mon, 25 Apr 2016 12:18:31 -0700 (PDT) Received: by 10.36.144.69 with HTTP; Mon, 25 Apr 2016 12:18:30 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F7CD82@ESESSMB209.ericsson.se> References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F27D6E@ESESSMB209.ericsson.se> <4F76BA3A-A69A-473E-97DA-287E6E571324@iii.ca> <5707C985.5060809@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37F7CD82@ESESSMB209.ericsson.se> Date: Mon, 25 Apr 2016 15:18:30 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=f46d04287571c174880531540a48 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 19:18:34 -0000 --f46d04287571c174880531540a48 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Apr 25, 2016 at 2:37 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >There is no indication what fingerprint applies to what certificate in > SDP fingerprint attribute. >The rule should be if connection is > established a certificate which matches at least one hash >that you > consider secure, the connection should be accepted. If you would make it > more >complicated, this will likely break backwards interop or would > require changes to >fingerprint/DTLS/certificates. > > > > I don=E2=80=99t want to make things complicated =E2=80=93 I want to agree= on something, > update the draft based on that, and go WGLC :) > > > I agree with trying to keep things simple. This means agreeing to something that is secure enough (one match for anything you consider secure is enough) vs trying to create something that is more secure (one fingerprint for each offered fingerprint hash algorithm must match). Regards, _____________ Roman Shpount --f46d04287571c174880531540a48 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 25, 2016 at 2:37 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

>Ther= e is no indication what fingerprint applies to what certificate in SDP fing= erprint attribute. >The rule should be if conne= ction is established a certificate which matches at least one hash >that you consider secure, t= he connection should be accepted. If you would make it more >complicated, this will like= ly break backwards interop or would require changes to >fingerprint/DTLS/certificat= es.

=C2=A0

I don=E2=80=99t want to make things complica= ted =E2=80=93 I want to agree on something, update the draft based on that,= and go WGLC :)


I agree with trying to keep things simple. This means agreeing= to something that is secure enough (one match for anything you consider se= cure is enough) vs trying to create something that is more secure (one fing= erprint for each offered fingerprint hash algorithm must match).
=
Regards,
__________= ___
Roman Shpount
=C2=A0
--f46d04287571c174880531540a48-- From nobody Mon Apr 25 12:26:18 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8507F12D6CC for ; Mon, 25 Apr 2016 12:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 r48m2z9gMih5 for ; Mon, 25 Apr 2016 12:26:14 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4169A12D6C8 for ; Mon, 25 Apr 2016 12:26:14 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-a1-571e6f540bdc Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4A.8E.18043.45F6E175; Mon, 25 Apr 2016 21:26:12 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0248.002; Mon, 25 Apr 2016 21:26:12 +0200 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] 4572 update: forbid weak hashes? Thread-Index: AQHRkMlvyALEPXgXDkKRhXLaT8/AmJ9+gkOg///n5gCAACIUsP//4eqAgAB6NgCAASWpgIAARJyAgBqMZgD//+CxgAAMKyYw///qVAD//90jgA== Date: Mon, 25 Apr 2016 19:26:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F7CF63@ESESSMB209.ericsson.se> References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F27D6E@ESESSMB209.ericsson.se> <4F76BA3A-A69A-473E-97DA-287E6E571324@iii.ca> <5707C985.5060809@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37F7CD82@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37F7CF63ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7hG5Ivly4waJP6hZTlz9msVix4QCr xYwLU5kdmD3+vv/A5LFkyU8mj1tTCgKYo7hsUlJzMstSi/TtErgyNnXfYCw4EFFxYPE8pgbG jrAuRk4OCQETib6VR9kgbDGJC/fWA9lcHEICRxgl7rdvYoVwljBK/Hl2g6mLkYODTcBCovuf NkiDiICqxN/vk5lAbGYBX4mXC74wg5QIC5hJXDseC1FiLvGzoZEFwq6TeHu/gRHEZgFqfTR/ H9hEXqDWOd/UIDa9Y5VYef0k2EhOgUCJvh0XwWxGoNu+n1oDtUpc4taT+UwQNwtILNlznhnC FpV4+fgfK4StJLFi+yVGiPp8iRNXm8FsXgFBiZMzn7BMYBSdhWTULCRls5CUzQI6j1lAU2L9 Ln2IEkWJKd0P2SFsDYnWOXPZkcUXMLKvYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiMvoNb flvtYDz43PEQowAHoxIP7wJO2XAh1sSy4srcQ4wSHMxKIrxLcuTChXhTEiurUovy44tKc1KL DzFKc7AoifPmRP4LExJITyxJzU5NLUgtgskycXBKNTAGpHlkbLlzhNHf+UP6jDd1Wjs/vzA5 7PzopYnxkRdJTfGrv1pznlD62RAXFWPwSrSI09Kmf/Uk6ZdL0mTubFg7b0MUzyeFWjbutVVC h2uPafq/sPk0b1lAidIZLYOelfYHn84+uGr9ornKC7MN9Bo45kqc65C7Wj3nx9OoYhVlG3FV 09B/RzcrsRRnJBpqMRcVJwIAxwHn4LoCAAA= Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 19:26:16 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37F7CF63ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28sIGRvZXMgYW55b25lIG9iamVjdCB0byB0aGUgcHJvcG9zYWw6IG5vIG1hdHRlciBob3cgbWFu eSBjZXJ0aWZpY2F0ZXMgKGFuZCBhc3NvY2lhdGVkIGZpbmdlcnByaW50cykgdGhlIFNEUCBjb250 YWlucywgYXMgbG9uZyBhcyB0aGVyZSBpcyAqb25lKiBoYXNoICh0aGF0IHRoZSByZWNlaXZlciBz dXBwb3J0cyBhbmQgY29uc2lkZXIgc2VjdXJlIGVub3VnaCkgbWF0Y2hlcyB0aGUgY2VydGlmaWNh dGUsIHRoaW5ncyBhcmUgZ29vZC4NCg0KKEkgYWdyZWUgdGhhdCBpcyBhbHNvIHRoZSBiZXN0IChv bmx5Pykgc29sdXRpb24gZnJvbSBhIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgcGVyc3BlY3RpdmUp DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IFJvbWFuIFNocG91bnQgW21haWx0bzpy b21hbkB0ZWx1cml4LmNvbV0NClNlbnQ6IDI1IEFwcmlsIDIwMTYgMjI6MTkNClRvOiBDaHJpc3Rl ciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KQ2M6IFBhdWwgS3l6 aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1PjsgbW11c2ljQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW01NVVNJQ10gNDU3MiB1cGRhdGU6IGZvcmJpZCB3ZWFrIGhhc2hlcz8NCg0KT24gTW9uLCBB cHIgMjUsIDIwMTYgYXQgMjozNyBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4g d3JvdGU6DQo+VGhlcmUgaXMgbm8gaW5kaWNhdGlvbiB3aGF0IGZpbmdlcnByaW50IGFwcGxpZXMg dG8gd2hhdCBjZXJ0aWZpY2F0ZSBpbiBTRFAgZmluZ2VycHJpbnQgYXR0cmlidXRlLiA+VGhlIHJ1 bGUgc2hvdWxkIGJlIGlmIGNvbm5lY3Rpb24gaXMgZXN0YWJsaXNoZWQgYSBjZXJ0aWZpY2F0ZSB3 aGljaCBtYXRjaGVzIGF0IGxlYXN0IG9uZSBoYXNoID50aGF0IHlvdSBjb25zaWRlciBzZWN1cmUs IHRoZSBjb25uZWN0aW9uIHNob3VsZCBiZSBhY2NlcHRlZC4gSWYgeW91IHdvdWxkIG1ha2UgaXQg bW9yZSA+Y29tcGxpY2F0ZWQsIHRoaXMgd2lsbCBsaWtlbHkgYnJlYWsgYmFja3dhcmRzIGludGVy b3Agb3Igd291bGQgcmVxdWlyZSBjaGFuZ2VzIHRvID5maW5nZXJwcmludC9EVExTL2NlcnRpZmlj YXRlcy4NCg0KSSBkb27igJl0IHdhbnQgdG8gbWFrZSB0aGluZ3MgY29tcGxpY2F0ZWQg4oCTIEkg d2FudCB0byBhZ3JlZSBvbiBzb21ldGhpbmcsIHVwZGF0ZSB0aGUgZHJhZnQgYmFzZWQgb24gdGhh dCwgYW5kIGdvIFdHTEMgOikNCg0KDQpJIGFncmVlIHdpdGggdHJ5aW5nIHRvIGtlZXAgdGhpbmdz IHNpbXBsZS4gVGhpcyBtZWFucyBhZ3JlZWluZyB0byBzb21ldGhpbmcgdGhhdCBpcyBzZWN1cmUg ZW5vdWdoIChvbmUgbWF0Y2ggZm9yIGFueXRoaW5nIHlvdSBjb25zaWRlciBzZWN1cmUgaXMgZW5v dWdoKSB2cyB0cnlpbmcgdG8gY3JlYXRlIHNvbWV0aGluZyB0aGF0IGlzIG1vcmUgc2VjdXJlIChv bmUgZmluZ2VycHJpbnQgZm9yIGVhY2ggb2ZmZXJlZCBmaW5nZXJwcmludCBoYXNoIGFsZ29yaXRo bSBtdXN0IG1hdGNoKS4NCg0KUmVnYXJkcywNCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQN Cg0K --_000_7594FB04B1934943A5C02806D1A2204B37F7CF63ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U28sIGRvZXMgYW55b25lIG9iamVjdCB0byB0 aGUgcHJvcG9zYWw6IG5vIG1hdHRlciBob3cgbWFueSBjZXJ0aWZpY2F0ZXMgKGFuZCBhc3NvY2lh dGVkIGZpbmdlcnByaW50cykgdGhlIFNEUCBjb250YWlucywgYXMgbG9uZyBhcw0KIHRoZXJlIGlz ICo8Yj5vbmU8L2I+KiBoYXNoICh0aGF0IHRoZSByZWNlaXZlciBzdXBwb3J0cyBhbmQgY29uc2lk ZXIgc2VjdXJlIGVub3VnaCkgbWF0Y2hlcyB0aGUgY2VydGlmaWNhdGUsIHRoaW5ncyBhcmUgZ29v ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPihJIGFncmVlIHRoYXQg aXMgYWxzbyB0aGUgYmVzdCAob25seT8pIHNvbHV0aW9uIGZyb20gYSBiYWNrd2FyZCBjb21wYXRp YmlsaXR5IHBlcnNwZWN0aXZlKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlz dGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0i X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUm9tYW4gU2hwb3VudCBbbWFp bHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDI1IEFwcmlsIDIwMTYg MjI6MTk8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBQYXVsIEt5eml2YXQgJmx0O3Br eXppdmF0QGFsdW0ubWl0LmVkdSZndDs7IG1tdXNpY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW01NVVNJQ10gNDU3MiB1cGRhdGU6IGZvcmJpZCB3ZWFrIGhhc2hlcz88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBN b24sIEFwciAyNSwgMjAxNiBhdCAyOjM3IFBNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9z cGFuPlRoZXJlIGlzIG5vIGluZGljYXRpb24gd2hhdCBmaW5nZXJwcmludCBhcHBsaWVzIHRvIHdo YXQgY2VydGlmaWNhdGUgaW4gU0RQIGZpbmdlcnByaW50IGF0dHJpYnV0ZS4NCjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPlRoZSBydWxlIHNob3VsZCBiZSBpZiBjb25uZWN0 aW9uIGlzIGVzdGFibGlzaGVkIGEgY2VydGlmaWNhdGUgd2hpY2ggbWF0Y2hlcyBhdCBsZWFzdCBv bmUgaGFzaA0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+dGhhdCB5b3Ug Y29uc2lkZXIgc2VjdXJlLCB0aGUgY29ubmVjdGlvbiBzaG91bGQgYmUgYWNjZXB0ZWQuIElmIHlv dSB3b3VsZCBtYWtlIGl0IG1vcmUNCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9z cGFuPmNvbXBsaWNhdGVkLCB0aGlzIHdpbGwgbGlrZWx5IGJyZWFrIGJhY2t3YXJkcyBpbnRlcm9w IG9yIHdvdWxkIHJlcXVpcmUgY2hhbmdlcyB0bw0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PiZndDs8L3NwYW4+ZmluZ2VycHJpbnQvRFRMUy9jZXJ0aWZpY2F0ZXMuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCB3YW50IHRvIG1h a2UgdGhpbmdzIGNvbXBsaWNhdGVkIOKAkyBJIHdhbnQgdG8gYWdyZWUgb24gc29tZXRoaW5nLCB1 cGRhdGUgdGhlIGRyYWZ0IGJhc2VkIG9uIHRoYXQsDQogYW5kIGdvIFdHTEMgOik8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHdpdGggdHJ5aW5nIHRvIGtlZXAgdGhpbmdz IHNpbXBsZS4gVGhpcyBtZWFucyBhZ3JlZWluZyB0byBzb21ldGhpbmcgdGhhdCBpcyBzZWN1cmUg ZW5vdWdoIChvbmUgbWF0Y2ggZm9yIGFueXRoaW5nIHlvdSBjb25zaWRlciBzZWN1cmUgaXMgZW5v dWdoKSB2cyB0cnlpbmcgdG8gY3JlYXRlIHNvbWV0aGluZyB0aGF0IGlzIG1vcmUgc2VjdXJlIChv bmUgZmluZ2VycHJpbnQgZm9yIGVhY2ggb2ZmZXJlZA0KIGZpbmdlcnByaW50IGhhc2ggYWxnb3Jp dGhtIG11c3QgbWF0Y2gpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B37F7CF63ESESSMB209erics_-- From nobody Mon Apr 25 12:56:23 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3E112B034 for ; Mon, 25 Apr 2016 12:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 eOTr8eAcf1m9 for ; Mon, 25 Apr 2016 12:56:21 -0700 (PDT) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A1D12B015 for ; Mon, 25 Apr 2016 12:56:21 -0700 (PDT) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by comcast with SMTP id umabasYF1YPZXumcGaGZ2V; Mon, 25 Apr 2016 19:56:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1461614180; bh=T800Q0NjHHGuQXvn+Pt1hTA4fQ9Y0hg88GoIZIpOYrg=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=JzTw9jBx+Qb1uwZo6Rng1J2EZV855Ox11eo5sScWJVNJ2klR1bhjJW+xPP3JHYfqv 0VaAf+31uBE9QO7+Lb9ixyS8O3gqWOk2lx+e//9NPuUi2Q86OMvCpK3uNpVYVI7fri iak6Kr4vxL2o8gyzV6it27iGujFoQ1TqGM6btiyHMCJm3SUlPSiKWA+nvVQuclhXUk aqxZAjMXdBpEoi0LidHhbJwzCswdvPo26MmU7bKkSdC8ypWriolqxnhUL3H6YnvGdW 0UoP19WIznOupvOJIhj76qEDRATeOftw/hnpE28R397r3I6O82S5iHESPpeH6jwVSO AtcungFRL6beg== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-09v.sys.comcast.net with comcast id mjwK1s00o3KdFy101jwKqe; Mon, 25 Apr 2016 19:56:20 +0000 To: Christer Holmberg , Roman Shpount References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F27D6E@ESESSMB209.ericsson.se> <4F76BA3A-A69A-473E-97DA-287E6E571324@iii.ca> <5707C985.5060809@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37F7CD82@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F7CF63@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <07073395-7f19-0a3b-b39b-38e1db51c391@alum.mit.edu> Date: Mon, 25 Apr 2016 15:56:19 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F7CF63@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 19:56:22 -0000 On 4/25/16 3:26 PM, Christer Holmberg wrote: > So, does anyone object to the proposal: no matter how many certificates > (and associated fingerprints) the SDP contains, as long as there is > **one** hash (that the receiver supports and consider secure enough) > matches the certificate, things are good. The possibility that the fingerprints might cover multiple certs, for multiple connections, messes things up. IIUC, *if* there is only one connection to be protected then all the fingerprints must be fingerprints of the cert for that one. And in that case if you check one and it fails to match then there is indeed an error, even if another one matches. Should it be acceptable to consider this case a failure? Or is this too complicated? One possibility would be to state that the minimum check, that MUST be applied, is that at least one fingerprint MUST match every cert covered by the SDP, and that an optional check (MAY be applied) is that *each* fingerprint match one of the certs covered by the SDP. (The optional check is something that a formal tester/verifier might perform.) It would be a requirement that the sender ensure that the harder test succeed if the recipient applies it. I can live with just the minimum being stated. Thanks, Paul > (I agree that is also the best (only?) solution from a backward > compatibility perspective) > > > > Regards, > > > > Christer > > > > *From:*Roman Shpount [mailto:roman@telurix.com] > *Sent:* 25 April 2016 22:19 > *To:* Christer Holmberg > *Cc:* Paul Kyzivat ; mmusic@ietf.org > *Subject:* Re: [MMUSIC] 4572 update: forbid weak hashes? > > > > On Mon, Apr 25, 2016 at 2:37 PM, Christer Holmberg > > > wrote: > > >There is no indication what fingerprint applies to what certificate > in SDP fingerprint attribute. >The rule should be if connection is > established a certificate which matches at least one hash >that you > consider secure, the connection should be accepted. If you would > make it more >complicated, this will likely break backwards interop > or would require changes to >fingerprint/DTLS/certificates. > > > > I don’t want to make things complicated – I want to agree on > something, update the draft based on that, and go WGLC :) > > > > > > I agree with trying to keep things simple. This means agreeing to > something that is secure enough (one match for anything you consider > secure is enough) vs trying to create something that is more secure (one > fingerprint for each offered fingerprint hash algorithm must match). > > > > Regards, > > _____________ > Roman Shpount > > > From nobody Mon Apr 25 13:11:35 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD7612D117 for ; Mon, 25 Apr 2016 13:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 uzzBuk5s7_VH for ; Mon, 25 Apr 2016 13:11:32 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 762CB12D0C9 for ; Mon, 25 Apr 2016 13:11:32 -0700 (PDT) Received: by mail-ig0-x22e.google.com with SMTP id bi2so77391787igb.0 for ; Mon, 25 Apr 2016 13:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=w/ITXw5/751h3AbTHIIp5N7xiwXqOwgjkXvRJasmabI=; b=Hg78GaUHad3po+H3j7SNW/TxlDKDEF0YdKj/Cmqg1KK/VjH+CnYjhcetnmp/01zaJL IDHiMaMw1AhmLc3ho9kKLB3Lhc8U1fn3bWIBwcuXcbapHqfvZ7LWStmAhtvF2UHNSW/B mFWKFzHUjhxUq1l16ABkZSjtgqRiVqU6BONKQOmP1qrIQ+ACvogxp26ye5lfAKhJRfBT F21gojlitr1xN0wmBLjB20p4GQ6ejWyBjTzKnPYcTIirk3eW5K79uExIaSfVs5LsAKBm Uj0loT/8EuMxk1r3UrLGZK60aWTReSnfPekURXD1qJtRWNvT3/eqAx3+o0WXYy+OHbVh Unrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=w/ITXw5/751h3AbTHIIp5N7xiwXqOwgjkXvRJasmabI=; b=S8AenXvSQ21a2aAGrFI4k1iRSewgSj+qoO86LtK34XXNXyucZx/W5l99ANiRf0ZAjC r84clxpAWB6zsDVo84W5MsAFTRlNf0MZFZUP3fT3j8R/rK/xyszcDdZjXsOHlZy2SDis dFajjaINbM0PqiGSRLsQLKxZd15wn9YRNf5gGEGP6lA0U6RFmm8Sz53EghL48PTfWtjh 6fGxLd657kPUr26FHEVOpKUAF3V45NBf3eZaTPYqcFMNE3jJSCtDcT2ZqOFN9Ma5ouAf 4wCe2p3OPg7X5MM6mGSp1ZbgnSWv2yKmpVsT9wG7e6NkEqZiCO+KJMbkVsq8o8W4eOkO c5KA== X-Gm-Message-State: AOPr4FUeJrezRTly1skttO6YKpstUUU0r/hQGvu5xjWcRCvzrheVdh+PaS4f4laSEl9llA== X-Received: by 10.50.33.176 with SMTP id s16mr13663399igi.86.1461615091727; Mon, 25 Apr 2016 13:11:31 -0700 (PDT) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com. [209.85.213.175]) by smtp.gmail.com with ESMTPSA id i14sm7510904iod.34.2016.04.25.13.11.30 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2016 13:11:30 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id g8so84765254igr.0 for ; Mon, 25 Apr 2016 13:11:30 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.119.67 with SMTP id ks3mr10021486igb.78.1461615090596; Mon, 25 Apr 2016 13:11:30 -0700 (PDT) Received: by 10.36.144.69 with HTTP; Mon, 25 Apr 2016 13:11:30 -0700 (PDT) In-Reply-To: <07073395-7f19-0a3b-b39b-38e1db51c391@alum.mit.edu> References: <4D60EE45-BECA-4A46-98EF-FF4AA482B42E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37F27B70@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F27D6E@ESESSMB209.ericsson.se> <4F76BA3A-A69A-473E-97DA-287E6E571324@iii.ca> <5707C985.5060809@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37F7CD82@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F7CF63@ESESSMB209.ericsson.se> <07073395-7f19-0a3b-b39b-38e1db51c391@alum.mit.edu> Date: Mon, 25 Apr 2016 16:11:30 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e011847f646053e053154c827 Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] 4572 update: forbid weak hashes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 20:11:34 -0000 --089e011847f646053e053154c827 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 25, 2016 at 3:56 PM, Paul Kyzivat wrote: > On 4/25/16 3:26 PM, Christer Holmberg wrote: > >> So, does anyone object to the proposal: no matter how many certificates >> (and associated fingerprints) the SDP contains, as long as there is >> **one** hash (that the receiver supports and consider secure enough) >> matches the certificate, things are good. >> > > The possibility that the fingerprints might cover multiple certs, for > multiple connections, messes things up. > > IIUC, *if* there is only one connection to be protected then all the > fingerprints must be fingerprints of the cert for that one. And in that > case if you check one and it fails to match then there is indeed an error, > even if another one matches. > > Should it be acceptable to consider this case a failure? Or is this too > complicated? > There is still a use case when an offer is sent but it is not yet known which of the several media processors will be used when connection is actually established. Such offer will contain fingerprints for certificates on all the media processors, but only one of them will match. This is true even for a single connection (bundle). > > One possibility would be to state that the minimum check, that MUST be > applied, is that at least one fingerprint MUST match every cert covered by > the SDP, and that an optional check (MAY be applied) is that *each* > fingerprint match one of the certs covered by the SDP. (The optional check > is something that a formal tester/verifier might perform.) It would be a > requirement that the sender ensure that the harder test succeed if the > recipient applies it. > We might add another SDP parameter for this or extend fingerprint in a backwards compatible way to indicate some sort of certificate group, but this is making things more complicated. Multiple people indicated that this is out of scope for this document revision. > I can live with just the minimum being stated. > We are mostly trying to document what people thought was already supported in maximum backwards compatible manner. I think minimum match is the only way. _____________ Roman Shpount --089e011847f646053e053154c827 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 25, 2016 at 3:56 PM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:
On 4/25/16 3:26 PM, Christer Holmberg wrote:
So, does anyone object to the proposal: no matter how many certificates
(and associated fingerprints) the SDP contains, as long as there is
**one** hash (that the receiver supports and consider secure enough)
matches the certificate, things are good.

The possibility that the fingerprints might cover multiple certs, for multi= ple connections, messes things up.

IIUC, *if* there is only one connection to be protected then all the finger= prints must be fingerprints of the cert for that one. And in that case if y= ou check one and it fails to match then there is indeed an error, even if a= nother one matches.

Should it be acceptable to consider this case a failure? Or is this too com= plicated?

There is still a use case whe= n an offer is sent but it is not yet known which of the several media proce= ssors will be used when connection is actually established. Such offer will= contain fingerprints for certificates on all the media processors, but onl= y one of them will match. This is true even for a single connection (bundle= ).

One possibility would be to state that the minimum check, that MUST be appl= ied, is that at least one fingerprint MUST match every cert covered by the = SDP, and that an optional check (MAY be applied) is that *each* fingerprint= match one of the certs covered by the SDP. (The optional check is somethin= g that a formal tester/verifier might perform.) It would be a requirement t= hat the sender ensure that the harder test succeed if the recipient applies= it.

We might add another SDP parameter= for this or extend fingerprint in a backwards compatible way to indicate s= ome sort of certificate group, but this is making things more complicated. = Multiple people indicated that this is out of scope for this document revis= ion.
=C2=A0
I can live with just= the minimum being stated.

We are mostl= y trying to document what people thought was already supported in maximum b= ackwards compatible manner. I think minimum match is the only way.
_____________
Roman Shpount<= /div>
=C2=A0
--089e011847f646053e053154c827-- From nobody Tue Apr 26 00:27:00 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E77C12B042 for ; Tue, 26 Apr 2016 00:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2v2eBo0BX-E for ; Tue, 26 Apr 2016 00:26:58 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE3F612B03C for ; Tue, 26 Apr 2016 00:26:57 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-a3-571f183f2fb5 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A1.8A.12926.F381F175; Tue, 26 Apr 2016 09:26:55 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0248.002; Tue, 26 Apr 2016 09:26:37 +0200 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] DTLS-SDP: "actress" to always trigger new DTLS association? Thread-Index: AQHRnvJFE9/VC7yRi0qI3xYwkFAAip+aoFsAgABoMID//+WnAIAA/u+A Date: Tue, 26 Apr 2016 07:26:36 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37F7CE6F@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D344F1FD785Dchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsUyM2K7k669hHy4wbwGM4upyx+zWMy4MJXZ gcljyZKfTB63phQEMEVx2aSk5mSWpRbp2yVwZVy6sZO14LZUxcO5kQ2MR8W6GDk5JARMJKZe /MwCYYtJXLi3ng3EFhI4wihx4iJjFyMXkL2EUeLKnPfsXYwcHGwCFhLd/7RBakQEVCX+fp/M BBJmFlCXuLo4CCQsLBAs8fvlL2aIkhCJD3tWg5WICLhJXPlUDRJmAeq89nECO4jNK2Al0Tjv HQvEph4miR8H94L1cgoESiy8fhmsiBHotO+n1jCB2MwC4hK3nsxngjhZQGLJnvPMELaoxMvH /1hBbFEBPYl9L84zQsQVJXaebWeG6I2X6FgynRlisaDEyZlPWCYwis1CMnYWkrJZSMog4gYS 78/NZ4awtSWWLXwNZetLbPxylhHCtpY4sX0LC7KaBYwcqxhFi1OLk3LTjYz1Uosyk4uL8/P0 8lJLNjEC4/Lglt+qOxgvv3E8xCjAwajEw7vgtFy4EGtiWXFl7iFGCQ5mJRHeMEH5cCHelMTK qtSi/Pii0pzU4kOM0hwsSuK82ZH/woQE0hNLUrNTUwtSi2CyTBycUg2MAT/UV7AY5ERr62z/ 2p3JK/VFf57ytfgTE0x6qo1uz0kUaNbNmFTOXDJh8kqOmU7y9TUzpLz8XtvdV7iUEHFS0K3M Z/aDVMsjDBdbe0X4Ws4+OFi46blnxduGax/zbx2QqNHw6d75z+gbR+q117xz5vn8NkxfuXGa /vk7Jzl/b8/fN42jT2GDEktxRqKhFnNRcSIAsCaMbMcCAAA= Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-SDP: "actress" to always trigger new DTLS association? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Apr 2016 07:26:59 -0000 --_000_D344F1FD785Dchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, =85 >>I thought you earlier said that the fingerprint/dtls-association-id combi= nation must change when a new DTLS association is created, but in this exam= ple the offerer will not change the combination >Yes, for new implementation fingerprints/dtls-association-id must change f= or ONE OF THE SIDES. So, offerer might keep the the same fingerprint/dtls-a= ssociation-id, but if answerer changes them, new DTLS association will be c= reated. Ok. So, the draft needs to be clear that the combination of the offerer may= not change even if a new association is created. >I would like to disallow changing just the role by the answerer for anythi= ng new, but for legacy intro >creating a new association on just the role change needs to be supported (= even though I do not think anybody does this). We could always say that the answerer SHOULD NOT change the role, as long a= s the offerer is prepared for it to happen. Regards, Christer --_000_D344F1FD785Dchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <40B0909FDEB96049B732CA7F358CF819@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

=85 

>>I thought you earlier said that the fingerprint/dtls-asso= ciation-id combination must change when a new DTLS association is created, = but in this example the offerer will not change the combination

>Yes, for new implementation fingerprints/dtls-association-id must = change for ONE OF THE SIDES. So, offerer might keep the the same fingerprin= t/dtls-association-id, but if answerer changes them, new DTLS association w= ill be created.

Ok. So, the draft needs to be clear that the combination of the offere= r may not change even if a new association is created.

>I would like to disallow changing just the role by the answerer fo= r anything new, but for legacy intro 
>creating a new association on just the role change needs to be sup= ported (even though I do not think anybody does this).

We could always say that the answerer SHOULD NOT change the role, as l= ong as the offerer is prepared for it to happen.

Regards,

Christer
 
--_000_D344F1FD785Dchristerholmbergericssoncom_-- From nobody Tue Apr 26 12:48:39 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADB012B069 for ; Tue, 26 Apr 2016 12:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 KZhemSl0MOtO for ; Tue, 26 Apr 2016 12:48:35 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B562D12B038 for ; Tue, 26 Apr 2016 12:48:35 -0700 (PDT) Received: by mail-ob0-x22f.google.com with SMTP id j9so12253867obd.3 for ; Tue, 26 Apr 2016 12:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=0Hi+SXxTmGye+WtbeXHnmWLGl7HM8IjMxgmXCfZ0M4Q=; b=dxQm1NFrydWuVuW6WoVrE3txcOo9xzWpfeowedsYxt7xBLfmR4uX7nBH6MgtXX8FFj Xi7kIItc/cl6I2u6Cs92iAcuXQr8RTIFky39ydScM5SG/NSgP7LP61YxSMCbZCrn81H9 DsmM6rM9EEAh8NCZ3zhNOO6csyWTE/lx+9QHnfQ1A6u1D+51dSSt6q8hAT5kigrwHO+w wZOqMC2XLfrLmURdIDDjGppk+nHpG1VFMrd45sxrY5lWWFEDRbmPZ0bHDX+xRvQ3/S5E 3bBYZRbGARZvIBuXkgdmgfPDDkBKAX54/gq21Qb1D/IXbwrDD/ysLYGqJ9kQvkBkhqrY d1fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=0Hi+SXxTmGye+WtbeXHnmWLGl7HM8IjMxgmXCfZ0M4Q=; b=gMr4kSH4vIU9ZGiQiWtKrME1PuOxFokembuhB2TPGr7Ybuf/VVpJ2ESVS+U0RYmdwN Sbodb8Y08IiQMSUtTPkww7M/uTVCOfPtmWFisTyOW+QJ26gxHZSw1z0gmZhWbme66sZ3 bEd8r/mCpR/PBIiYXpBTwNYxQ5KTisVyck3draftFFosac7lpM1jDUyuODwXP1CW5QQv gpyRb9a+wKSVZK+ZHsfrktm/xZquRmIZS0yiUPBhgjDJGFK1XWAFT+jsM1Rjske8D5FG fFyH2IcyFU62zlMd5GFzD2omRUQSMclTGIfyL2go3jn/arCt0Tvm2ArbTtSEYdMNwEiM UNiQ== X-Gm-Message-State: AOPr4FVpVv3ywsI5jWTzs6u7O6dWvFrpXhdQA1OHc0wx3Y9qDm/5fhoAH6wDLgqoj2jBQQ== X-Received: by 10.60.38.8 with SMTP id c8mr1915323oek.45.1461700114948; Tue, 26 Apr 2016 12:48:34 -0700 (PDT) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com. [209.85.213.169]) by smtp.gmail.com with ESMTPSA id b7sm149451oej.16.2016.04.26.12.48.34 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Apr 2016 12:48:34 -0700 (PDT) Received: by mail-ig0-f169.google.com with SMTP id u10so52542266igr.1 for ; Tue, 26 Apr 2016 12:48:34 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.78.73 with SMTP id z9mr5834788igw.42.1461700113988; Tue, 26 Apr 2016 12:48:33 -0700 (PDT) Received: by 10.36.144.69 with HTTP; Tue, 26 Apr 2016 12:48:33 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37F7CE6F@ESESSMB209.ericsson.se> Date: Tue, 26 Apr 2016 15:48:33 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e0118275410098105316894c3 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-SDP: "actress" to always trigger new DTLS association? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Apr 2016 19:48:38 -0000 --089e0118275410098105316894c3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 26, 2016 at 3:26 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > =E2=80=A6 > > >>I thought you earlier said that the fingerprint/dtls-association-id > combination must change when a new DTLS association is created, but in th= is > example the offerer will not change the combination > >Yes, for new implementation fingerprints/dtls-association-id must change > for ONE OF THE SIDES. So, offerer might keep the the same > fingerprint/dtls-association-id, but if answerer changes them, new DTLS > association will be created. > > Ok. So, the draft needs to be clear that the combination of the offerer > may not change even if a new association is created. > We need to be clear that even if fingerprints and dtls-association-id stayed the same in the offer, new DTLS association must be created if they changed in the answer. Answerer SHOULD change fingerprints/dtls-association-id when new DTLS association is set up, but offerer should be able to handle answers with the same fingerprints/dtls-association-id even though fingerprints/dtls-association-id changed in the offer. >I would like to disallow changing just the role by the answerer for > anything new, but for legacy intro > >creating a new association on just the role change needs to be supported > (even though I do not think anybody does this). > > We could always say that the answerer SHOULD NOT change the role, as long > as the offerer is prepared for it to happen. > We should say that answerer SHOULD NOT change only the role in the answer without changing fingerprints/dtls-association-id, but offerer must be prepared to receive an answer with just the setup role changed and setup new DTLS association in this case. Regards, _____________ Roman Shpount --089e0118275410098105316894c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 26, 2016 at 3:26 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
=E2=80=A6=C2=A0

>>I thought you earlier said that the fingerprint/dtls-asso= ciation-id combination must change when a new DTLS association is created, = but in this example the offerer will not change the combination

>Yes, for new implementation fingerprints/dtls-association-i= d must change for ONE OF THE SIDES. So, offerer might keep the the same fin= gerprint/dtls-association-id, but if answerer changes them, new DTLS associ= ation will be created.=C2=A0

Ok. So, the draft needs to be clear that the combination of the offere= r may not change even if a new association is created.

We need to be clear that even if fingerprints and d= tls-association-id stayed the same in the offer, new DTLS association must = be created if they changed in the answer. Answerer SHOULD change fingerprin= ts/dtls-association-id when new DTLS association is set up, but offerer sho= uld be able to handle answers with the same fingerprints/dtls-association-i= d even though fingerprints/dtls-association-id changed in the offer.
<= div>
>I would like to disallow changing just the role by the answerer fo= r anything new, but for legacy intro=C2=A0
>creating a new association on just the role change needs to be sup= ported (even though I do not think anybody does this).

We could always say that the answerer SHOULD NOT change the rol= e, as long as the offerer is prepared for it to happen.

We should say that answerer SHOULD NOT change only= the role in the answer without changing fingerprints/dtls-association-id, = but offerer must be prepared to receive an answer with just the setup role = changed and setup new DTLS association in this case.

Regards,
_____________
Roman= Shpount
=C2=A0