From nobody Tue Aug 1 14:59:54 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE97E126B6E; Tue, 1 Aug 2017 14:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 l3PgRmjUj-vu; Tue, 1 Aug 2017 14:59:45 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 949EB124217; Tue, 1 Aug 2017 14:59:45 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v71LxefU037595 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 1 Aug 2017 16:59:41 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <150151861369.6298.12051161492632423089.idtracker@ietfa.amsl.com> Date: Tue, 1 Aug 2017 16:59:39 -0500 Cc: The IESG , avtcore-chairs@ietf.org, roni.even@huawei.com, draft-ietf-avtcore-aria-srtp@ietf.org, avt@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <644A4716-29C2-4F36-9B82-CD38113EA88E@nostrum.com> References: <150151861369.6298.12051161492632423089.idtracker@ietfa.amsl.com> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [AVTCORE] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-avtcore-aria-srtp-10=3A_=28with_COMMENT=29?= X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 21:59:47 -0000 > On Jul 31, 2017, at 11:30 AM, Mirja K=C3=BChlewind = wrote: >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > This actually looks more like a document that we would rather = typically publish > by the ISE (as it is describing a method employed by one specific = entity only). > I do not object to it publication as informational and I do understand = that > this mostly due to the registration the in the MIKEY registry, = however, i would > like to note that IESG Approval would have been another option for = this > registration. >=20 I think if this work were started from scratch in its current form, I = would agree with you. But the original version of this draft would have = required standards-action. That text has been removed, but by that time = most of the work had already been done in the working group. Given that = this has already completed IETF last call, the least-effort path seems = to be to approve it as an informational RFC on the IETF stream. Thanks! Ben.= From nobody Tue Aug 1 22:59:38 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192D7126CB6; Tue, 1 Aug 2017 22:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 xKRY-cqDKZlP; Tue, 1 Aug 2017 22:59:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94807126557; Tue, 1 Aug 2017 22:59:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSN58229; Wed, 02 Aug 2017 05:59:32 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 2 Aug 2017 06:59:31 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.170]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0301.000; Wed, 2 Aug 2017 13:59:27 +0800 From: Roni Even To: Ben Campbell , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= CC: The IESG , "avtcore-chairs@ietf.org" , "draft-ietf-avtcore-aria-srtp@ietf.org" , "avt@ietf.org" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-avtcore-aria-srtp-10:_(with_COMMENT)?= Thread-Index: AQHTChpNT4xEg5zW6UemdGP+nJ4o16JviKCAgAEJwyA= Date: Wed, 2 Aug 2017 05:59:27 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD7F1088@DGGEMM506-MBX.china.huawei.com> References: <150151861369.6298.12051161492632423089.idtracker@ietfa.amsl.com> <644A4716-29C2-4F36-9B82-CD38113EA88E@nostrum.com> In-Reply-To: <644A4716-29C2-4F36-9B82-CD38113EA88E@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.51] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0204.59816A45.0011, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.170, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2eeaae1e02e6645f70c0cafa977f86a3 Archived-At: Subject: Re: [AVTCORE] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-avtcore-aria-srtp-10=3A_=28with_COMMENT=29?= X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 05:59:37 -0000 SGksDQpJIHRoaW5rIHRoYXQgdGhpcyBwb2ludCBpcyBhIGdlbmVyYWwgcHJvYmxlbSBhbmQgc2hv dWxkIGJlIGFkZHJlc3NlZCBhcyBhIHJldmlldyBvZiB0aGUgcmVnaXN0cmF0aW9uIHByb2NlZHVy ZXMgZm9yIE1pa2V5LCBEVExTIGFuZCBTREVTLg0KVGhlIGxhY2sgb2YgY29uc2lzdGVuY3kgc3Rh cnRlZCB0aGlzIHdob2xlIGRpc2N1c3Npb24uDQoNClJvbmkgRXZlbg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJlbiBDYW1wYmVsbCBbbWFpbHRvOmJlbkBub3N0cnVt LmNvbV0NCj4gU2VudDog15nXldedwqDXkyAwMiDXkNeV15LXldeh15ggMjAxNyAwMTowMA0KPiBU bzogTWlyamEgS8O8aGxld2luZA0KPiBDYzogVGhlIElFU0c7IGF2dGNvcmUtY2hhaXJzQGlldGYu b3JnOyBSb25pIEV2ZW47IGRyYWZ0LWlldGYtYXZ0Y29yZS1hcmlhLQ0KPiBzcnRwQGlldGYub3Jn OyBhdnRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IE1pcmphIEvDvGhsZXdpbmQncyBObyBPYmpl Y3Rpb24gb24gZHJhZnQtaWV0Zi1hdnRjb3JlLWFyaWEtc3J0cC0NCj4gMTA6ICh3aXRoIENPTU1F TlQpDQo+IA0KPiANCj4gPiBPbiBKdWwgMzEsIDIwMTcsIGF0IDExOjMwIEFNLCBNaXJqYSBLw7xo bGV3aW5kIDxpZXRmQGt1ZWhsZXdpbmQubmV0Pg0KPiB3cm90ZToNCj4gPg0KPiA+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gPiBDT01NRU5UOg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPg0KPiA+IFRoaXMgYWN0 dWFsbHkgbG9va3MgbW9yZSBsaWtlIGEgZG9jdW1lbnQgdGhhdCB3ZSB3b3VsZCByYXRoZXINCj4g PiB0eXBpY2FsbHkgcHVibGlzaCBieSB0aGUgSVNFIChhcyBpdCBpcyBkZXNjcmliaW5nIGEgbWV0 aG9kIGVtcGxveWVkIGJ5IG9uZQ0KPiBzcGVjaWZpYyBlbnRpdHkgb25seSkuDQo+ID4gSSBkbyBu b3Qgb2JqZWN0IHRvIGl0IHB1YmxpY2F0aW9uIGFzIGluZm9ybWF0aW9uYWwgYW5kIEkgZG8gdW5k ZXJzdGFuZA0KPiA+IHRoYXQgdGhpcyBtb3N0bHkgZHVlIHRvIHRoZSByZWdpc3RyYXRpb24gdGhl IGluIHRoZSBNSUtFWSByZWdpc3RyeSwNCj4gPiBob3dldmVyLCBpIHdvdWxkIGxpa2UgdG8gbm90 ZSB0aGF0IElFU0cgQXBwcm92YWwgd291bGQgaGF2ZSBiZWVuDQo+ID4gYW5vdGhlciBvcHRpb24g Zm9yIHRoaXMgcmVnaXN0cmF0aW9uLg0KPiA+DQo+IA0KPiBJIHRoaW5rIGlmIHRoaXMgd29yayB3 ZXJlIHN0YXJ0ZWQgZnJvbSBzY3JhdGNoIGluIGl0cyBjdXJyZW50IGZvcm0sIEkgd291bGQNCj4g YWdyZWUgd2l0aCB5b3UuIEJ1dCB0aGUgb3JpZ2luYWwgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0IHdv dWxkIGhhdmUgcmVxdWlyZWQNCj4gc3RhbmRhcmRzLWFjdGlvbi4gVGhhdCB0ZXh0IGhhcyBiZWVu IHJlbW92ZWQsIGJ1dCBieSB0aGF0IHRpbWUgbW9zdCBvZiB0aGUNCj4gd29yayBoYWQgYWxyZWFk eSBiZWVuIGRvbmUgaW4gdGhlIHdvcmtpbmcgZ3JvdXAuIEdpdmVuIHRoYXQgdGhpcyBoYXMNCj4g YWxyZWFkeSBjb21wbGV0ZWQgSUVURiBsYXN0IGNhbGwsIHRoZSBsZWFzdC1lZmZvcnQgcGF0aCBz ZWVtcyB0byBiZSB0byBhcHByb3ZlDQo+IGl0IGFzIGFuIGluZm9ybWF0aW9uYWwgUkZDIG9uIHRo ZSBJRVRGIHN0cmVhbS4NCj4gDQo+IFRoYW5rcyENCj4gDQo+IEJlbi4NCg== From nobody Wed Aug 2 02:07:07 2017 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86581127978; Wed, 2 Aug 2017 02:07:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150166482650.5723.11383140618174819134@ietfa.amsl.com> Date: Wed, 02 Aug 2017 02:07:06 -0700 Archived-At: Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rfc5285-bis-14.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 09:07:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance WG of the IETF. Title : A General Mechanism for RTP Header Extensions Authors : David Singer Harikishan Desineni Roni Even Filename : draft-ietf-avtcore-rfc5285-bis-14.txt Pages : 24 Date : 2017-08-02 Abstract: This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. This document obsoletes RFC5285. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis-14 https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rfc5285-bis-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rfc5285-bis-14 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 Wed Aug 2 08:37:33 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40A813213D; Wed, 2 Aug 2017 08:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 rJd0_ZZO4qsD; Wed, 2 Aug 2017 08:37:30 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 CC926124B18; Wed, 2 Aug 2017 08:37:30 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v72FbMjS040607 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 2 Aug 2017 10:37:23 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD7F1088@DGGEMM506-MBX.china.huawei.com> Date: Wed, 2 Aug 2017 10:37:21 -0500 Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , The IESG , "avtcore-chairs@ietf.org" , "draft-ietf-avtcore-aria-srtp@ietf.org" , "avt@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3AA7C0C8-102B-4945-8161-4834AEC4EBCA@nostrum.com> References: <150151861369.6298.12051161492632423089.idtracker@ietfa.amsl.com> <644A4716-29C2-4F36-9B82-CD38113EA88E@nostrum.com> <6E58094ECC8D8344914996DAD28F1CCD7F1088@DGGEMM506-MBX.china.huawei.com> To: Roni Even X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [AVTCORE] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-avtcore-aria-srtp-10=3A_=28with_COMMENT=29?= X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 15:37:32 -0000 > On Aug 2, 2017, at 12:59 AM, Roni Even wrote: >=20 > Hi, > I think that this point is a general problem and should be addressed = as a review of the registration procedures for Mikey, DTLS and SDES. > The lack of consistency started this whole discussion. It is my understanding that the inconsistency is intentional, in that = people wanted a higher bar to add new things for SDES because they = wanted to discourage the expansion of its use. It=E2=80=99s reasonable = to discuss whether that still makes sense.=20 But I don=E2=80=99t think we want to block _this_ draft on that = discussion=E2=80=94that=E2=80=99s the reason we removed the SDES = registration from it in the first place. >=20 > Roni Even >=20 >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: =D7=99=D7=95=D7=9D =D7=93 02 =D7=90=D7=95=D7=92=D7=95=D7=A1=D7=98= 2017 01:00 >> To: Mirja K=C3=BChlewind >> Cc: The IESG; avtcore-chairs@ietf.org; Roni Even; = draft-ietf-avtcore-aria- >> srtp@ietf.org; avt@ietf.org >> Subject: Re: Mirja K=C3=BChlewind's No Objection on = draft-ietf-avtcore-aria-srtp- >> 10: (with COMMENT) >>=20 >>=20 >>> On Jul 31, 2017, at 11:30 AM, Mirja K=C3=BChlewind = >> wrote: >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> This actually looks more like a document that we would rather >>> typically publish by the ISE (as it is describing a method employed = by one >> specific entity only). >>> I do not object to it publication as informational and I do = understand >>> that this mostly due to the registration the in the MIKEY registry, >>> however, i would like to note that IESG Approval would have been >>> another option for this registration. >>>=20 >>=20 >> I think if this work were started from scratch in its current form, I = would >> agree with you. But the original version of this draft would have = required >> standards-action. That text has been removed, but by that time most = of the >> work had already been done in the working group. Given that this has >> already completed IETF last call, the least-effort path seems to be = to approve >> it as an informational RFC on the IETF stream. >>=20 >> Thanks! >>=20 >> Ben. From nobody Wed Aug 2 18:50:52 2017 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6411321A9; Wed, 2 Aug 2017 18:50:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-avtcore-aria-srtp@ietf.org, Roni Even , avtcore-chairs@ietf.org, roni.even@huawei.com, avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150172505031.5791.14553211399724965332.idtracker@ietfa.amsl.com> Date: Wed, 02 Aug 2017 18:50:50 -0700 Archived-At: Subject: [AVTCORE] Kathleen Moriarty's No Objection on draft-ietf-avtcore-aria-srtp-10: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 01:50:50 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-avtcore-aria-srtp-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Although this is not a discuss, I think updated text would be very helpful on the following two issues. I agree with the SecDir reviewer that there should be more text around the short tag length in the security considerations section. I don't see a response to that post though. For SHA-1, a reference to RFC6194 for the security considerations for SHA-1message digest algorithms would be helpful. Thank you! From nobody Wed Aug 2 19:36:47 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F201321C0; Wed, 2 Aug 2017 19:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 GpfYZqEFePXF; Wed, 2 Aug 2017 19:36:38 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2717D129A96; Wed, 2 Aug 2017 19:36:38 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v732aVgX053591 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 2 Aug 2017 21:36:32 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <150172505031.5791.14553211399724965332.idtracker@ietfa.amsl.com> Date: Wed, 2 Aug 2017 21:36:31 -0500 Cc: The IESG , avtcore-chairs@ietf.org, roni.even@huawei.com, draft-ietf-avtcore-aria-srtp@ietf.org, avt@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <084BEE4A-1241-42C6-BD39-36F11792ABB4@nostrum.com> References: <150172505031.5791.14553211399724965332.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on draft-ietf-avtcore-aria-srtp-10: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 02:36:39 -0000 > On Aug 2, 2017, at 8:50 PM, Kathleen Moriarty = wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Although this is not a discuss, I think updated text would be very = helpful on > the following two issues. >=20 > I agree with the SecDir reviewer that there should be more text around = the > short tag length in the security considerations section. I don't see = a > response to that post though. >=20 Hi Kathleen, I think you are referring to Ben Laurie=E2=80=99s SecDir review of 06, = rather than his later review of 09. Is that correct? Version 9 removed = the GCM_8 modes. Or were you referring to something else? > For SHA-1, a reference to RFC6194 for the security considerations for > SHA-1message digest algorithms would be helpful. Thank you! Thanks, that=E2=80=99s helpful. I agree the security considerations = needs to say something about the use of SHA1 Ben.= From nobody Wed Aug 2 19:50:52 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD0512FEE2; Wed, 2 Aug 2017 19:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 9I9HjNe7E1rA; Wed, 2 Aug 2017 19:50:43 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e: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 B71AC129A96; Wed, 2 Aug 2017 19:50:43 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id l64so654699pge.5; Wed, 02 Aug 2017 19:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Ivh8xCIVfHUtnSbkKlKFt9gDZnR0P7yUYf6apJEPxro=; b=DkTEW84G4V9/TJCurJgojJYoRtaqBGAVDf7EYZOIgNnh4mKoMikQXgT5lroSiPymQ2 rq94rOvaD8PcswKf+uDW/zQCCpnz6Dkr4lKNbsOE1vAP3TLyWMmzrnYCJjdbvxxvHX9S 2+Rw2aXjbSSAaeqHGvGdF4VkYk9EDRC8qYizdZ+WmgztM7z/WM/9eIQKPhzlP+WCydxZ YBEwLTqIoVoML0YUCOt80FcXZJr/LQrMUxwzeXcy4Q/xMqe7HDmqhKvVHlsJseizu+q0 64+TLCTgMsKvbnjDr9TxnUWO8TOjDgXS4d3Ox/HZvQwsP2O4jvWGv32Wt1R7oX7SFfz9 OAQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Ivh8xCIVfHUtnSbkKlKFt9gDZnR0P7yUYf6apJEPxro=; b=DxTApb/Jn2HW/evHMaTZ8iW2vNVmTTt0Jvz+WVqAmIhlWPIdTDobX+QhxtZb/h8Uvo zSstTfDnvB/2SaokqwWBz2NpLwHcZBsBJZR1+tSDnEBCp3sPVlwZ/83kDsI/O6INawdx lzv9k36W9nGS6CgDNCcYX60+MdfhqNehejzZAnCoQWQ3NNYjpto5ADzZTIdSIK1poCNq GST2KDxKOt2tiL9vFAsGzYFe0luRSbDzHlS3LyKsa4zjWhrSn0rtwciO9oSseMT++QjY E1n9cdigUsrMna2riait5UMZhMnybcAABI1hABPfsCraIhGTeCe7ZknbAtcgqLgxsC+I Zb3w== X-Gm-Message-State: AIVw1100Tcx+RkMGyCi2l+wFnCjQWbKbaMIe65SU+FEUhQy9bnYrfo83 zc20iVY8Hvliw4jv6vXaycXTOJ+iu6qF X-Received: by 10.101.76.76 with SMTP id l12mr150053pgr.161.1501728643376; Wed, 02 Aug 2017 19:50:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.144.1 with HTTP; Wed, 2 Aug 2017 19:50:02 -0700 (PDT) In-Reply-To: <084BEE4A-1241-42C6-BD39-36F11792ABB4@nostrum.com> References: <150172505031.5791.14553211399724965332.idtracker@ietfa.amsl.com> <084BEE4A-1241-42C6-BD39-36F11792ABB4@nostrum.com> From: Kathleen Moriarty Date: Wed, 2 Aug 2017 22:50:02 -0400 Message-ID: To: Ben Campbell Cc: The IESG , avtcore-chairs@ietf.org, Roni Even , draft-ietf-avtcore-aria-srtp@ietf.org, avt@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on draft-ietf-avtcore-aria-srtp-10: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 02:50:45 -0000 Hi Ben, Thanks for the quick response, inline. On Wed, Aug 2, 2017 at 10:36 PM, Ben Campbell wrote: > > > >> On Aug 2, 2017, at 8:50 PM, Kathleen Moriarty wrote: >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Although this is not a discuss, I think updated text would be very helpf= ul on >> the following two issues. >> >> I agree with the SecDir reviewer that there should be more text around t= he >> short tag length in the security considerations section. I don't see a >> response to that post though. >> > > Hi Kathleen, > > I think you are referring to Ben Laurie=E2=80=99s SecDir review of 06, ra= ther than his later review of 09. Is that correct? Version 9 removed the GC= M_8 modes. Or were you referring to something else? I am referring to Ben's review of -06, where he had the following text: Thirdly, I am not familiar enough with SRTP to understand why short authentication tags are needed, but in general its a bad idea, so I feel the Security Considerations should explain more fully than "Ciphersuites with short tag length may be considered for specific application environments stated in 7.5 of [RFC3711], but the risk of weak authentication described in Section 9.5.1 of [RFC3711] should be taken into account." I don't see an update to this text to address his question - providing additional information as to what should be "taken into account". > >> For SHA-1, a reference to RFC6194 for the security considerations for >> SHA-1message digest algorithms would be helpful. Thank you! > > Thanks, that=E2=80=99s helpful. I agree the security considerations needs= to say something about the use of SHA1 Great, thanks! > > Ben. --=20 Best regards, Kathleen From nobody Wed Aug 2 20:16:05 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F291321C6; Wed, 2 Aug 2017 20:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 mranTbkFtymF; Wed, 2 Aug 2017 20:15:53 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 EF19C1317E3; Wed, 2 Aug 2017 20:15:52 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v733FkCD060204 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 2 Aug 2017 22:15:47 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Wed, 2 Aug 2017 22:15:45 -0500 Cc: The IESG , avtcore-chairs@ietf.org, Roni Even , draft-ietf-avtcore-aria-srtp@ietf.org, avt@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150172505031.5791.14553211399724965332.idtracker@ietfa.amsl.com> <084BEE4A-1241-42C6-BD39-36F11792ABB4@nostrum.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on draft-ietf-avtcore-aria-srtp-10: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 03:16:04 -0000 > On Aug 2, 2017, at 9:50 PM, Kathleen Moriarty = wrote: >=20 > Hi Ben, >=20 > Thanks for the quick response, inline. >=20 > On Wed, Aug 2, 2017 at 10:36 PM, Ben Campbell wrote: >>=20 >>=20 >>=20 >>> On Aug 2, 2017, at 8:50 PM, Kathleen Moriarty = wrote: >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> Although this is not a discuss, I think updated text would be very = helpful on >>> the following two issues. >>>=20 >>> I agree with the SecDir reviewer that there should be more text = around the >>> short tag length in the security considerations section. I don't = see a >>> response to that post though. >>>=20 >>=20 >> Hi Kathleen, >>=20 >> I think you are referring to Ben Laurie=E2=80=99s SecDir review of = 06, rather than his later review of 09. Is that correct? Version 9 = removed the GCM_8 modes. Or were you referring to something else? >=20 > I am referring to Ben's review of -06, where he had the following = text: >=20 > Thirdly, I am not familiar enough with SRTP to understand why short > authentication tags are needed, but in general its a bad idea, so I > feel the Security Considerations should explain more fully than > "Ciphersuites with short tag length may be > considered for specific application environments stated in 7.5 of > [RFC3711], but the risk of weak authentication described in > Section 9.5.1 of [RFC3711] should be taken into account." >=20 > I don't see an update to this text to address his question - providing > additional information as to what should be "taken into account=E2=80=9D= . I had assumed his concern was about short tags in GCM mode, namely the = following:=20 AEAD_ARIA_128_GCM_8=20 AEAD_ARIA_256_GCM_8 AEAD_ARIA_128_GCM_12=20 AEAD_ARIA_256_GCM_12=20 These have all been removed as of version 09. Ben=E2=80=99s review of 09 = made no further mention of short tags. Are there suites still in version 09 that you think need further = discussion in the security considerations? I think the authors would = happily add something if we can tell them what is needed, but I=E2=80=99m = certainly not the expert here. Ben. From nobody Thu Aug 3 06:27:36 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157BF131FFA; Thu, 3 Aug 2017 06:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 f13BAfyB4sSq; Thu, 3 Aug 2017 06:27:32 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 61A4B131FFD; Thu, 3 Aug 2017 06:27:32 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id d67so6405766pfc.0; Thu, 03 Aug 2017 06:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5j3EdWQq0jeWfMArBoqyOYfx8wlmd6MR17HoiEqMYec=; b=LujsaNIhLhm+ZYP9tVlS0O64QqKAo20+7ULes7g/bx4YbPMd94twmIcfjTHLPnWlL4 XqsOIUurbpm9+Io4t3E4Af0EmnwEDLGO254xCAp4RUxXIvnrT1UT+8a1OtaeIzJw5Nfd 95GbCtUJwMR6jaGYoYY41uCJCwkAwwYAePyAqCeEpjbNllUYPt5R6xDMYCG9owZO0j4p JtnyPRfQ8WyEqxRg9d14bLnO/iqG1ugFCJXLzA4dap9dtk1m3tarloTTTUPK9uJECwoD Gi15YGd19LoWxq0gHDyKp5P2yJnwmQv1h8o0N15fjPncRVkA3qUSGmn34wgHBaq3w0XG Iz7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5j3EdWQq0jeWfMArBoqyOYfx8wlmd6MR17HoiEqMYec=; b=nE7FqHKJmkySqIXAeGLcJq1+fdrZKgPNsPdYxIzPvKUzFZaIc7xzfqHjh5hJYipWM6 9IHHt1AjG+QOy9oLI8ZeTWK8ycmRlkcuhTssUS7is0N9sGh19rQ3feWjULu/s2d3rVs0 bmuw4Wetb0VcbE3vjm3sS4AdFCSBpI6UraXUFL1VhCPGaRPh368YIP/ZqTHCcgS9aBDa TEzzPQa5FZTuoVuS6CYXtgzhtmsbRHM4seOjrpPHibSc9sOt8cZoAZ7FDFAaUbPr+nfM DfnA4FndwBtz/3NXjU2z28F6WgKoxwRE7HypZyLE21vBrHdDQU+mmVwRDFaszEBgvR1Q S+Eg== X-Gm-Message-State: AIVw111ET7kTqiKKVtfgNxEOK1wzKuOoafNZKlS7C0DGCSbGXZr/qfGc T2Mfd4J6XEOdMaOecq+8CE4BeUPhlw== X-Received: by 10.84.129.103 with SMTP id 94mr1888900plb.63.1501766851979; Thu, 03 Aug 2017 06:27:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.144.1 with HTTP; Thu, 3 Aug 2017 06:26:51 -0700 (PDT) In-Reply-To: References: <150172505031.5791.14553211399724965332.idtracker@ietfa.amsl.com> <084BEE4A-1241-42C6-BD39-36F11792ABB4@nostrum.com> From: Kathleen Moriarty Date: Thu, 3 Aug 2017 09:26:51 -0400 Message-ID: To: Ben Campbell Cc: The IESG , avtcore-chairs@ietf.org, Roni Even , draft-ietf-avtcore-aria-srtp@ietf.org, avt@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on draft-ietf-avtcore-aria-srtp-10: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 13:27:34 -0000 Hi Ben, On Wed, Aug 2, 2017 at 11:15 PM, Ben Campbell wrote: > >> On Aug 2, 2017, at 9:50 PM, Kathleen Moriarty wrote: >> >> Hi Ben, >> >> Thanks for the quick response, inline. >> >> On Wed, Aug 2, 2017 at 10:36 PM, Ben Campbell wrote: >>> >>> >>> >>>> On Aug 2, 2017, at 8:50 PM, Kathleen Moriarty wrote: >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> Although this is not a discuss, I think updated text would be very hel= pful on >>>> the following two issues. >>>> >>>> I agree with the SecDir reviewer that there should be more text around= the >>>> short tag length in the security considerations section. I don't see = a >>>> response to that post though. >>>> >>> >>> Hi Kathleen, >>> >>> I think you are referring to Ben Laurie=E2=80=99s SecDir review of 06, = rather than his later review of 09. Is that correct? Version 9 removed the = GCM_8 modes. Or were you referring to something else? >> >> I am referring to Ben's review of -06, where he had the following text: >> >> Thirdly, I am not familiar enough with SRTP to understand why short >> authentication tags are needed, but in general its a bad idea, so I >> feel the Security Considerations should explain more fully than >> "Ciphersuites with short tag length may be >> considered for specific application environments stated in 7.5 of >> [RFC3711], but the risk of weak authentication described in >> Section 9.5.1 of [RFC3711] should be taken into account." >> >> I don't see an update to this text to address his question - providing >> additional information as to what should be "taken into account=E2=80=9D= . > > I had assumed his concern was about short tags in GCM mode, namely the fo= llowing: > > AEAD_ARIA_128_GCM_8 > AEAD_ARIA_256_GCM_8 > AEAD_ARIA_128_GCM_12 > AEAD_ARIA_256_GCM_12 > > These have all been removed as of version 09. Ben=E2=80=99s review of 09 = made no further mention of short tags. Thanks, but the text warning about them remains in the security considerations section. Is it needed for some reason? Kathleen > > Are there suites still in version 09 that you think need further discussi= on in the security considerations? I think the authors would happily add s= omething if we can tell them what is needed, but I=E2=80=99m certainly not = the expert here. > > Ben. > --=20 Best regards, Kathleen From nobody Thu Aug 3 06:55:55 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C44132027; Thu, 3 Aug 2017 06:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 kGJK_vVFpC86; Thu, 3 Aug 2017 06:55:52 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 ABD50132043; Thu, 3 Aug 2017 06:55:52 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v73DtfMj072515 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 3 Aug 2017 08:55:42 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Thu, 3 Aug 2017 08:55:42 -0500 Cc: The IESG , avtcore-chairs@ietf.org, Roni Even , draft-ietf-avtcore-aria-srtp@ietf.org, avt@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150172505031.5791.14553211399724965332.idtracker@ietfa.amsl.com> <084BEE4A-1241-42C6-BD39-36F11792ABB4@nostrum.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on draft-ietf-avtcore-aria-srtp-10: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 13:55:54 -0000 > On Aug 3, 2017, at 8:26 AM, Kathleen Moriarty = wrote: >=20 > Hi Ben, >=20 > On Wed, Aug 2, 2017 at 11:15 PM, Ben Campbell wrote: >>=20 >>> On Aug 2, 2017, at 9:50 PM, Kathleen Moriarty = wrote: >>>=20 >>> Hi Ben, >>>=20 >>> Thanks for the quick response, inline. >>>=20 >>> On Wed, Aug 2, 2017 at 10:36 PM, Ben Campbell = wrote: >>>>=20 >>>>=20 >>>>=20 >>>>> On Aug 2, 2017, at 8:50 PM, Kathleen Moriarty = wrote: >>>>> = ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> Although this is not a discuss, I think updated text would be very = helpful on >>>>> the following two issues. >>>>>=20 >>>>> I agree with the SecDir reviewer that there should be more text = around the >>>>> short tag length in the security considerations section. I don't = see a >>>>> response to that post though. >>>>>=20 >>>>=20 >>>> Hi Kathleen, >>>>=20 >>>> I think you are referring to Ben Laurie=E2=80=99s SecDir review of = 06, rather than his later review of 09. Is that correct? Version 9 = removed the GCM_8 modes. Or were you referring to something else? >>>=20 >>> I am referring to Ben's review of -06, where he had the following = text: >>>=20 >>> Thirdly, I am not familiar enough with SRTP to understand why short >>> authentication tags are needed, but in general its a bad idea, so I >>> feel the Security Considerations should explain more fully than >>> "Ciphersuites with short tag length may be >>> considered for specific application environments stated in 7.5 of >>> [RFC3711], but the risk of weak authentication described in >>> Section 9.5.1 of [RFC3711] should be taken into account." >>>=20 >>> I don't see an update to this text to address his question - = providing >>> additional information as to what should be "taken into account=E2=80=9D= . >>=20 >> I had assumed his concern was about short tags in GCM mode, namely = the following: >>=20 >> AEAD_ARIA_128_GCM_8 >> AEAD_ARIA_256_GCM_8 >> AEAD_ARIA_128_GCM_12 >> AEAD_ARIA_256_GCM_12 >>=20 >> These have all been removed as of version 09. Ben=E2=80=99s review of = 09 made no further mention of short tags. >=20 > Thanks, but the text warning about them remains in the security > considerations section. Is it needed for some reason? >=20 Ah, I get it=E2=80=94I thought you were asking for _more_ text :-). I = think they put that in as a result of the 06 review, but didn=E2=80=99t = take it out when they removed those modes. I will verify that the = authors don=E2=80=99t think the warning applies to any of the remaining. Ben. > Kathleen >=20 >>=20 >> Are there suites still in version 09 that you think need further = discussion in the security considerations? I think the authors would = happily add something if we can tell them what is needed, but I=E2=80=99m = certainly not the expert here. >>=20 >> Ben. >>=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen From nobody Thu Aug 3 13:24:15 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F3E129AB2 for ; Thu, 3 Aug 2017 13:24:14 -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=qasimkhan-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 aYkUheo96HhY for ; Thu, 3 Aug 2017 13:24:01 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 D9FC4131C8A for ; Thu, 3 Aug 2017 13:24:00 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id h199so3026013ith.0 for ; Thu, 03 Aug 2017 13:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qasimkhan-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=OYQajhWL6Ht1gzhDtOTld/OmtXBa6hzGYLQidbLRqhw=; b=r/CNPmrxIJ1olAyj13ZIPVS4lB8hf7phOhNwFulNMklUDT3fgpBvix5r6w8r+xIWOk V5w7XMAmGxM7RfdBW7WODdhMm30Mi/8/4Lll5B5XiiycJB+ytJvSQDOua+jgULIxLIGJ cQCUkPnEtVJI1qVgH+tiCuv+Fw3uILZ92rID01sHoD/HAU541YglxNVqLOLqI2Iu6KjH LpcR7XgkuMmGxjs/ZhHqJxzq2BCM+qma1LMscOzyq0ekHb6P4Y/4/Q3+f9py4Z87CDR3 rHYAOXeFyhNWl9tQ2c1mYDU1L0QWUBo3/vK1qbiEij94dC3qfqcG+fARtXwwK/gjN7YT WDVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OYQajhWL6Ht1gzhDtOTld/OmtXBa6hzGYLQidbLRqhw=; b=oNA8gEoZGUUT3ukNOoY9WEd0WRIXw2lVgerhWtcb/B41tLqduAmmbGF7QvmVHYoJlJ GQ/tI9Qu4jWp+eEzRQP0gWp7Ei0CYDZpgPBqVJOfPfhsUBDvIscA8RI7NVKWrkRYMjOS dDhETjUMdkpDFbP/0mNbbHp0R3vg8WGpuDMgYPL1G6X0KeMmStu4mQrqBsFnDm8wORbQ lnI0pt2EixPpScS3lXb4q2s4Pa7waZHH+/k0X1o+PgBkl4wuqRA/5duECoBWYdQ9ccWK aya+GTiT4EC16x7Jn8Eil9cV4O746VWpHmDXs8KUyCdnrC5iCe3lrzV1vtd8sIoivqXN C9Dw== X-Gm-Message-State: AIVw113N+yIusYde0ROqjxUYXrxKrNgl47Up/rQdZPVQfcs5DnjA3Pa4 JtNW3v54Pr5LDio+56eYGTZwypympR75 X-Received: by 10.36.116.146 with SMTP id o140mr614763itc.107.1501791839726; Thu, 03 Aug 2017 13:23:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.2.216 with HTTP; Thu, 3 Aug 2017 13:23:59 -0700 (PDT) From: "Qasim Y. Khan" Date: Fri, 4 Aug 2017 01:23:59 +0500 Message-ID: To: avt@ietf.org Content-Type: multipart/alternative; boundary="001a114aaadc22756a0555df2952" Archived-At: Subject: [AVTCORE] help X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 20:24:14 -0000 --001a114aaadc22756a0555df2952 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 3, 2017 at 6:55 PM, wrote: > Send avt mailing list submissions to > avt@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/avt > or, via email, send a message with subject or body 'help' to > avt-request@ietf.org > > You can reach the person managing the list at > avt-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of avt digest..." > > > Today's Topics: > > 1. Kathleen Moriarty's No Objection on > draft-ietf-avtcore-aria-srtp-10: (with COMMENT) (Kathleen Moriarty) > 2. Re: Kathleen Moriarty's No Objection on > draft-ietf-avtcore-aria-srtp-10: (with COMMENT) (Ben Campbell) > 3. Re: Kathleen Moriarty's No Objection on > draft-ietf-avtcore-aria-srtp-10: (with COMMENT) (Kathleen Moriarty) > 4. Re: Kathleen Moriarty's No Objection on > draft-ietf-avtcore-aria-srtp-10: (with COMMENT) (Ben Campbell) > 5. Re: Kathleen Moriarty's No Objection on > draft-ietf-avtcore-aria-srtp-10: (with COMMENT) (Kathleen Moriarty) > 6. Re: Kathleen Moriarty's No Objection on > draft-ietf-avtcore-aria-srtp-10: (with COMMENT) (Ben Campbell) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 02 Aug 2017 18:50:50 -0700 > From: Kathleen Moriarty > To: "The IESG" > Cc: draft-ietf-avtcore-aria-srtp@ietf.org, Roni Even > , avtcore-chairs@ietf.org, > roni.even@huawei.com, > avt@ietf.org > Subject: [AVTCORE] Kathleen Moriarty's No Objection on > draft-ietf-avtcore-aria-srtp-10: (with COMMENT) > Message-ID: > <150172505031.5791.14553211399724965332.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset="utf-8" > > Kathleen Moriarty has entered the following ballot position for > draft-ietf-avtcore-aria-srtp-10: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Although this is not a discuss, I think updated text would be very helpful > on > the following two issues. > > I agree with the SecDir reviewer that there should be more text around the > short tag length in the security considerations section. I don't see a > response to that post though. > > For SHA-1, a reference to RFC6194 for the security considerations for > SHA-1message digest algorithms would be helpful. Thank you! > > > > > ------------------------------ > > Message: 2 > Date: Wed, 2 Aug 2017 21:36:31 -0500 > From: Ben Campbell > To: Kathleen Moriarty > Cc: The IESG , avtcore-chairs@ietf.org, > roni.even@huawei.com, draft-ietf-avtcore-aria-srtp@ietf.org, > avt@ietf.org > Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on > draft-ietf-avtcore-aria-srtp-10: (with COMMENT) > Message-ID: <084BEE4A-1241-42C6-BD39-36F11792ABB4@nostrum.com> > Content-Type: text/plain; charset=utf-8 > > > > > > On Aug 2, 2017, at 8:50 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Although this is not a discuss, I think updated text would be very > helpful on > > the following two issues. > > > > I agree with the SecDir reviewer that there should be more text around > the > > short tag length in the security considerations section. I don't see a > > response to that post though. > > > > Hi Kathleen, > > I think you are referring to Ben Laurie?s SecDir review of 06, rather than > his later review of 09. Is that correct? Version 9 removed the GCM_8 modes. > Or were you referring to something else? > > > For SHA-1, a reference to RFC6194 for the security considerations for > > SHA-1message digest algorithms would be helpful. Thank you! > > Thanks, that?s helpful. I agree the security considerations needs to say > something about the use of SHA1 > > Ben. > > > ------------------------------ > > Message: 3 > Date: Wed, 2 Aug 2017 22:50:02 -0400 > From: Kathleen Moriarty > To: Ben Campbell > Cc: The IESG , avtcore-chairs@ietf.org, Roni Even > , draft-ietf-avtcore-aria-srtp@ietf.org, > avt@ietf.org > Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on > draft-ietf-avtcore-aria-srtp-10: (with COMMENT) > Message-ID: > -YUMHaLsXxuw@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi Ben, > > Thanks for the quick response, inline. > > On Wed, Aug 2, 2017 at 10:36 PM, Ben Campbell wrote: > > > > > > > >> On Aug 2, 2017, at 8:50 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> Although this is not a discuss, I think updated text would be very > helpful on > >> the following two issues. > >> > >> I agree with the SecDir reviewer that there should be more text around > the > >> short tag length in the security considerations section. I don't see a > >> response to that post though. > >> > > > > Hi Kathleen, > > > > I think you are referring to Ben Laurie?s SecDir review of 06, rather > than his later review of 09. Is that correct? Version 9 removed the GCM_8 > modes. Or were you referring to something else? > > I am referring to Ben's review of -06, where he had the following text: > > Thirdly, I am not familiar enough with SRTP to understand why short > authentication tags are needed, but in general its a bad idea, so I > feel the Security Considerations should explain more fully than > "Ciphersuites with short tag length may be > considered for specific application environments stated in 7.5 of > [RFC3711], but the risk of weak authentication described in > Section 9.5.1 of [RFC3711] should be taken into account." > > I don't see an update to this text to address his question - providing > additional information as to what should be "taken into account". > > > > > >> For SHA-1, a reference to RFC6194 for the security considerations for > >> SHA-1message digest algorithms would be helpful. Thank you! > > > > Thanks, that?s helpful. I agree the security considerations needs to say > something about the use of SHA1 > > Great, thanks! > > > > Ben. > > > > -- > > Best regards, > Kathleen > > > > ------------------------------ > > Message: 4 > Date: Wed, 2 Aug 2017 22:15:45 -0500 > From: Ben Campbell > To: Kathleen Moriarty > Cc: The IESG , avtcore-chairs@ietf.org, Roni Even > , draft-ietf-avtcore-aria-srtp@ietf.org, > avt@ietf.org > Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on > draft-ietf-avtcore-aria-srtp-10: (with COMMENT) > Message-ID: > Content-Type: text/plain; charset=utf-8 > > > > On Aug 2, 2017, at 9:50 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > > > Hi Ben, > > > > Thanks for the quick response, inline. > > > > On Wed, Aug 2, 2017 at 10:36 PM, Ben Campbell wrote: > >> > >> > >> > >>> On Aug 2, 2017, at 8:50 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >>> ---------------------------------------------------------------------- > >>> COMMENT: > >>> ---------------------------------------------------------------------- > >>> > >>> Although this is not a discuss, I think updated text would be very > helpful on > >>> the following two issues. > >>> > >>> I agree with the SecDir reviewer that there should be more text around > the > >>> short tag length in the security considerations section. I don't see a > >>> response to that post though. > >>> > >> > >> Hi Kathleen, > >> > >> I think you are referring to Ben Laurie?s SecDir review of 06, rather > than his later review of 09. Is that correct? Version 9 removed the GCM_8 > modes. Or were you referring to something else? > > > > I am referring to Ben's review of -06, where he had the following text: > > > > Thirdly, I am not familiar enough with SRTP to understand why short > > authentication tags are needed, but in general its a bad idea, so I > > feel the Security Considerations should explain more fully than > > "Ciphersuites with short tag length may be > > considered for specific application environments stated in 7.5 of > > [RFC3711], but the risk of weak authentication described in > > Section 9.5.1 of [RFC3711] should be taken into account." > > > > I don't see an update to this text to address his question - providing > > additional information as to what should be "taken into account?. > > I had assumed his concern was about short tags in GCM mode, namely the > following: > > AEAD_ARIA_128_GCM_8 > AEAD_ARIA_256_GCM_8 > AEAD_ARIA_128_GCM_12 > AEAD_ARIA_256_GCM_12 > > These have all been removed as of version 09. Ben?s review of 09 made no > further mention of short tags. > > Are there suites still in version 09 that you think need further > discussion in the security considerations? I think the authors would > happily add something if we can tell them what is needed, but I?m certainly > not the expert here. > > Ben. > > > > ------------------------------ > > Message: 5 > Date: Thu, 3 Aug 2017 09:26:51 -0400 > From: Kathleen Moriarty > To: Ben Campbell > Cc: The IESG , avtcore-chairs@ietf.org, Roni Even > , draft-ietf-avtcore-aria-srtp@ietf.org, > avt@ietf.org > Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on > draft-ietf-avtcore-aria-srtp-10: (with COMMENT) > Message-ID: > mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi Ben, > > On Wed, Aug 2, 2017 at 11:15 PM, Ben Campbell wrote: > > > >> On Aug 2, 2017, at 9:50 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> > >> Hi Ben, > >> > >> Thanks for the quick response, inline. > >> > >> On Wed, Aug 2, 2017 at 10:36 PM, Ben Campbell wrote: > >>> > >>> > >>> > >>>> On Aug 2, 2017, at 8:50 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >>>> ------------------------------------------------------------ > ---------- > >>>> COMMENT: > >>>> ------------------------------------------------------------ > ---------- > >>>> > >>>> Although this is not a discuss, I think updated text would be very > helpful on > >>>> the following two issues. > >>>> > >>>> I agree with the SecDir reviewer that there should be more text > around the > >>>> short tag length in the security considerations section. I don't see > a > >>>> response to that post though. > >>>> > >>> > >>> Hi Kathleen, > >>> > >>> I think you are referring to Ben Laurie?s SecDir review of 06, rather > than his later review of 09. Is that correct? Version 9 removed the GCM_8 > modes. Or were you referring to something else? > >> > >> I am referring to Ben's review of -06, where he had the following text: > >> > >> Thirdly, I am not familiar enough with SRTP to understand why short > >> authentication tags are needed, but in general its a bad idea, so I > >> feel the Security Considerations should explain more fully than > >> "Ciphersuites with short tag length may be > >> considered for specific application environments stated in 7.5 of > >> [RFC3711], but the risk of weak authentication described in > >> Section 9.5.1 of [RFC3711] should be taken into account." > >> > >> I don't see an update to this text to address his question - providing > >> additional information as to what should be "taken into account?. > > > > I had assumed his concern was about short tags in GCM mode, namely the > following: > > > > AEAD_ARIA_128_GCM_8 > > AEAD_ARIA_256_GCM_8 > > AEAD_ARIA_128_GCM_12 > > AEAD_ARIA_256_GCM_12 > > > > These have all been removed as of version 09. Ben?s review of 09 made no > further mention of short tags. > > Thanks, but the text warning about them remains in the security > considerations section. Is it needed for some reason? > > Kathleen > > > > > Are there suites still in version 09 that you think need further > discussion in the security considerations? I think the authors would > happily add something if we can tell them what is needed, but I?m certainly > not the expert here. > > > > Ben. > > > > > > -- > > Best regards, > Kathleen > > > > ------------------------------ > > Message: 6 > Date: Thu, 3 Aug 2017 08:55:42 -0500 > From: Ben Campbell > To: Kathleen Moriarty > Cc: The IESG , avtcore-chairs@ietf.org, Roni Even > , draft-ietf-avtcore-aria-srtp@ietf.org, > avt@ietf.org > Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on > draft-ietf-avtcore-aria-srtp-10: (with COMMENT) > Message-ID: > Content-Type: text/plain; charset=utf-8 > > > > On Aug 3, 2017, at 8:26 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > > > Hi Ben, > > > > On Wed, Aug 2, 2017 at 11:15 PM, Ben Campbell wrote: > >> > >>> On Aug 2, 2017, at 9:50 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >>> > >>> Hi Ben, > >>> > >>> Thanks for the quick response, inline. > >>> > >>> On Wed, Aug 2, 2017 at 10:36 PM, Ben Campbell wrote: > >>>> > >>>> > >>>> > >>>>> On Aug 2, 2017, at 8:50 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >>>>> ------------------------------------------------------------ > ---------- > >>>>> COMMENT: > >>>>> ------------------------------------------------------------ > ---------- > >>>>> > >>>>> Although this is not a discuss, I think updated text would be very > helpful on > >>>>> the following two issues. > >>>>> > >>>>> I agree with the SecDir reviewer that there should be more text > around the > >>>>> short tag length in the security considerations section. I don't > see a > >>>>> response to that post though. > >>>>> > >>>> > >>>> Hi Kathleen, > >>>> > >>>> I think you are referring to Ben Laurie?s SecDir review of 06, rather > than his later review of 09. Is that correct? Version 9 removed the GCM_8 > modes. Or were you referring to something else? > >>> > >>> I am referring to Ben's review of -06, where he had the following text: > >>> > >>> Thirdly, I am not familiar enough with SRTP to understand why short > >>> authentication tags are needed, but in general its a bad idea, so I > >>> feel the Security Considerations should explain more fully than > >>> "Ciphersuites with short tag length may be > >>> considered for specific application environments stated in 7.5 of > >>> [RFC3711], but the risk of weak authentication described in > >>> Section 9.5.1 of [RFC3711] should be taken into account." > >>> > >>> I don't see an update to this text to address his question - providing > >>> additional information as to what should be "taken into account?. > >> > >> I had assumed his concern was about short tags in GCM mode, namely the > following: > >> > >> AEAD_ARIA_128_GCM_8 > >> AEAD_ARIA_256_GCM_8 > >> AEAD_ARIA_128_GCM_12 > >> AEAD_ARIA_256_GCM_12 > >> > >> These have all been removed as of version 09. Ben?s review of 09 made > no further mention of short tags. > > > > Thanks, but the text warning about them remains in the security > > considerations section. Is it needed for some reason? > > > > Ah, I get it?I thought you were asking for _more_ text :-). I think they > put that in as a result of the 06 review, but didn?t take it out when they > removed those modes. I will verify that the authors don?t think the warning > applies to any of the remaining. > > Ben. > > > Kathleen > > > >> > >> Are there suites still in version 09 that you think need further > discussion in the security considerations? I think the authors would > happily add something if we can tell them what is needed, but I?m certainly > not the expert here. > >> > >> Ben. > >> > > > > > > > > -- > > > > Best regards, > > Kathleen > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > > ------------------------------ > > End of avt Digest, Vol 160, Issue 2 > *********************************** > --001a114aaadc22756a0555df2952 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


= On Thu, Aug 3, 2017 at 6:55 PM, <avt-request@ietf.org> w= rote:
Send avt mailing list submissions t= o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 avt@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/avt
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 avt-req= uest@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 avt-owner= @ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of avt digest..."


Today's Topics:

=C2=A0 =C2=A01. Kathleen Moriarty's No Objection on
=C2=A0 =C2=A0 =C2=A0 draft-ietf-avtcore-aria-srtp-10: (with COMMENT) (= Kathleen Moriarty)
=C2=A0 =C2=A02. Re: Kathleen Moriarty's No Objection on
=C2=A0 =C2=A0 =C2=A0 draft-ietf-avtcore-aria-srtp-10: (with COMMENT) (= Ben Campbell)
=C2=A0 =C2=A03. Re: Kathleen Moriarty's No Objection on
=C2=A0 =C2=A0 =C2=A0 draft-ietf-avtcore-aria-srtp-10: (with COMMENT) (= Kathleen Moriarty)
=C2=A0 =C2=A04. Re: Kathleen Moriarty's No Objection on
=C2=A0 =C2=A0 =C2=A0 draft-ietf-avtcore-aria-srtp-10: (with COMMENT) (= Ben Campbell)
=C2=A0 =C2=A05. Re: Kathleen Moriarty's No Objection on
=C2=A0 =C2=A0 =C2=A0 draft-ietf-avtcore-aria-srtp-10: (with COMMENT) (= Kathleen Moriarty)
=C2=A0 =C2=A06. Re: Kathleen Moriarty's No Objection on
=C2=A0 =C2=A0 =C2=A0 draft-ietf-avtcore-aria-srtp-10: (with COMMENT) (= Ben Campbell)


-----------------------------------------------------------------= -----

Message: 1
Date: Wed, 02 Aug 2017 18:50:50 -0700
From: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
To: "The IESG" <iesg@ietf.org= >
Cc: draft-ietf-avt= core-aria-srtp@ietf.org, Roni Even
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <ron= i.even@huawei.com>, avtco= re-chairs@ietf.org, roni.even@h= uawei.com,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 avt@ietf.org
Subject: [AVTCORE] Kathleen Moriarty's No Objection on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-avtcore-aria-srtp-10: (with COM= MENT)
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <150172505031.5791.145532113997= 24965332.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=3D"utf-8"

Kathleen Moriarty has entered the following ballot position for
draft-ietf-avtcore-aria-srtp-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/= draft-ietf-avtcore-aria-srtp/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Although this is not a discuss, I think updated text would be very helpful = on
the following two issues.

I agree with the SecDir reviewer that there should be more text around the<= br> short tag length in the security considerations section.=C2=A0 I don't = see a
response to that post though.

For SHA-1, a reference to RFC6194 for the security considerations for
SHA-1message digest algorithms would be helpful. Thank you!




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

Message: 2
Date: Wed, 2 Aug 2017 21:36:31 -0500
From: Ben Campbell <ben@nostrum.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, avtcore-chairs@ietf.org,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 roni.ev= en@huawei.com, draft-ietf-avtcore-aria-srtp@ietf.org,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 avt@ietf.org
Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-avtcore-aria-srtp-10: (with COM= MENT)
Message-ID: <084BEE4A-1241-42C6-BD39-36F11792ABB4@nostrum.com>
Content-Type: text/plain; charset=3Dutf-8




> On Aug 2, 2017, at 8:50 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com&g= t; wrote:
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> Although this is not a discuss, I think updated text would be very hel= pful on
> the following two issues.
>
> I agree with the SecDir reviewer that there should be more text around= the
> short tag length in the security considerations section.=C2=A0 I don&#= 39;t see a
> response to that post though.
>

Hi Kathleen,

I think you are referring to Ben Laurie?s SecDir review of 06, rather than = his later review of 09. Is that correct? Version 9 removed the GCM_8 modes.= Or were you referring to something else?

> For SHA-1, a reference to RFC6194 for the security considerations for<= br> > SHA-1message digest algorithms would be helpful. Thank you!

Thanks, that?s helpful. I agree the security considerations needs to say so= mething about the use of SHA1

Ben.


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

Message: 3
Date: Wed, 2 Aug 2017 22:50:02 -0400
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: Ben Campbell <ben@nostrum.com= >
Cc: The IESG <iesg@ietf.org>, avtcore-chairs@ietf.org,=C2=A0= Roni Even
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <ron= i.even@huawei.com>, draft-ietf-avtcore-aria-srtp@ietf.org,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 avt@ietf.org
Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-avtcore-aria-srtp-10: (with COM= MENT)
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAHbuEH4+R8KguTtLdoGnGdom= 1YB6Cp0XD5nLTm-YUMHaLsXxuw@mail.gmail.com>
Content-Type: text/plain; charset=3D"UTF-8"

Hi Ben,

Thanks for the quick response, inline.

On Wed, Aug 2, 2017 at 10:36 PM, Ben Campbell <ben@nostrum.com> wrote:
>
>
>
>> On Aug 2, 2017, at 8:50 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
>> ------------------------------------------------------------<= wbr>----------
>> COMMENT:
>> ------------------------------------------------------------<= wbr>----------
>>
>> Although this is not a discuss, I think updated text would be very= helpful on
>> the following two issues.
>>
>> I agree with the SecDir reviewer that there should be more text ar= ound the
>> short tag length in the security considerations section.=C2=A0 I d= on't see a
>> response to that post though.
>>
>
> Hi Kathleen,
>
> I think you are referring to Ben Laurie?s SecDir review of 06, rather = than his later review of 09. Is that correct? Version 9 removed the GCM_8 m= odes. Or were you referring to something else?

I am referring to Ben's review of -06, where he had the following text:=

Thirdly, I am not familiar enough with SRTP to understand why short
authentication tags are needed, but in general its a bad idea, so I
feel the Security Considerations should explain more fully than
"Ciphersuites with short tag length may be
=C2=A0 =C2=A0considered for specific application environments stated in 7.5= of
=C2=A0 =C2=A0[RFC3711], but the risk of weak authentication described in =C2=A0 =C2=A0Section 9.5.1 of [RFC3711] should be taken into account."=

I don't see an update to this text to address his question - providing<= br> additional information as to what should be "taken into account".=


>
>> For SHA-1, a reference to RFC6194 for the security considerations = for
>> SHA-1message digest algorithms would be helpful. Thank you!
>
> Thanks, that?s helpful. I agree the security considerations needs to s= ay something about the use of SHA1

Great, thanks!
>
> Ben.



--

Best regards,
Kathleen



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

Message: 4
Date: Wed, 2 Aug 2017 22:15:45 -0500
From: Ben Campbell <ben@nostrum.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, avtcore-chairs@ietf.org, Roni = Even
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <ron= i.even@huawei.com>, draft-ietf-avtcore-aria-srtp@ietf.org,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 avt@ietf.org
Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-avtcore-aria-srtp-10: (with COM= MENT)
Message-ID: <D666082B-4DBF-406E-AC6C-03493A376A53@nostrum.com>
Content-Type: text/plain; charset=3Dutf-8


> On Aug 2, 2017, at 9:50 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com&g= t; wrote:
>
> Hi Ben,
>
> Thanks for the quick response, inline.
>
> On Wed, Aug 2, 2017 at 10:36 PM, Ben Campbell <ben@nostrum.com> wrote:
>>
>>
>>
>>> On Aug 2, 2017, at 8:50 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.c= om> wrote:
>>> ---------------------------------------------------------= -------------
>>> COMMENT:
>>> ---------------------------------------------------------= -------------
>>>
>>> Although this is not a discuss, I think updated text would be = very helpful on
>>> the following two issues.
>>>
>>> I agree with the SecDir reviewer that there should be more tex= t around the
>>> short tag length in the security considerations section.=C2=A0= I don't see a
>>> response to that post though.
>>>
>>
>> Hi Kathleen,
>>
>> I think you are referring to Ben Laurie?s SecDir review of 06, rat= her than his later review of 09. Is that correct? Version 9 removed the GCM= _8 modes. Or were you referring to something else?
>
> I am referring to Ben's review of -06, where he had the following = text:
>
> Thirdly, I am not familiar enough with SRTP to understand why short > authentication tags are needed, but in general its a bad idea, so I > feel the Security Considerations should explain more fully than
> "Ciphersuites with short tag length may be
>=C2=A0 =C2=A0considered for specific application environments stated in= 7.5 of
>=C2=A0 =C2=A0[RFC3711], but the risk of weak authentication described i= n
>=C2=A0 =C2=A0Section 9.5.1 of [RFC3711] should be taken into account.&q= uot;
>
> I don't see an update to this text to address his question - provi= ding
> additional information as to what should be "taken into account?.=

I had assumed his concern was about short tags in GCM mode, namely the foll= owing:

=C2=A0 =C2=A0 =C2=A0 =C2=A0AEAD_ARIA_128_GCM_8
=C2=A0 =C2=A0 =C2=A0 =C2=A0AEAD_ARIA_256_GCM_8
=C2=A0 =C2=A0 =C2=A0 =C2=A0AEAD_ARIA_128_GCM_12
=C2=A0 =C2=A0 =C2=A0 =C2=A0AEAD_ARIA_256_GCM_12

These have all been removed as of version 09. Ben?s review of 09 made no fu= rther mention of short tags.

Are there suites still in version 09 that you think need further discussion= in the security considerations?=C2=A0 I think the authors would happily ad= d something if we can tell them what is needed, but I?m certainly not the e= xpert here.

Ben.



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

Message: 5
Date: Thu, 3 Aug 2017 09:26:51 -0400
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: Ben Campbell <ben@nostrum.com= >
Cc: The IESG <iesg@ietf.org>, avtcore-chairs@ietf.org,=C2=A0= Roni Even
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <ron= i.even@huawei.com>, draft-ietf-avtcore-aria-srtp@ietf.org,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 avt@ietf.org
Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-avtcore-aria-srtp-10: (with COM= MENT)
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAHbuEH6JJNq9QmAi9Dbg15-S= ctUS+c6FArW94KqfRzVP_g4gGw@mail.gmail.com>
Content-Type: text/plain; charset=3D"UTF-8"

Hi Ben,

On Wed, Aug 2, 2017 at 11:15 PM, Ben Campbell <ben@nostrum.com> wrote:
>
>> On Aug 2, 2017, at 9:50 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
>>
>> Hi Ben,
>>
>> Thanks for the quick response, inline.
>>
>> On Wed, Aug 2, 2017 at 10:36 PM, Ben Campbell <ben@nostrum.com> wrote:
>>>
>>>
>>>
>>>> On Aug 2, 2017, at 8:50 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.<= wbr>com> wrote:
>>>> -----------------------------------------------------= -----------------
>>>> COMMENT:
>>>> -----------------------------------------------------= -----------------
>>>>
>>>> Although this is not a discuss, I think updated text would= be very helpful on
>>>> the following two issues.
>>>>
>>>> I agree with the SecDir reviewer that there should be more= text around the
>>>> short tag length in the security considerations section.= =C2=A0 I don't see a
>>>> response to that post though.
>>>>
>>>
>>> Hi Kathleen,
>>>
>>> I think you are referring to Ben Laurie?s SecDir review of 06,= rather than his later review of 09. Is that correct? Version 9 removed the= GCM_8 modes. Or were you referring to something else?
>>
>> I am referring to Ben's review of -06, where he had the follow= ing text:
>>
>> Thirdly, I am not familiar enough with SRTP to understand why shor= t
>> authentication tags are needed, but in general its a bad idea, so = I
>> feel the Security Considerations should explain more fully than >> "Ciphersuites with short tag length may be
>>=C2=A0 =C2=A0considered for specific application environments state= d in 7.5 of
>>=C2=A0 =C2=A0[RFC3711], but the risk of weak authentication describ= ed in
>>=C2=A0 =C2=A0Section 9.5.1 of [RFC3711] should be taken into accoun= t."
>>
>> I don't see an update to this text to address his question - p= roviding
>> additional information as to what should be "taken into accou= nt?.
>
> I had assumed his concern was about short tags in GCM mode, namely the= following:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 AEAD_ARIA_128_GCM_8
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 AEAD_ARIA_256_GCM_8
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 AEAD_ARIA_128_GCM_12
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 AEAD_ARIA_256_GCM_12
>
> These have all been removed as of version 09. Ben?s review of 09 made = no further mention of short tags.

Thanks, but the text warning about them remains in the security
considerations section.=C2=A0 Is it needed for some reason?

Kathleen

>
> Are there suites still in version 09 that you think need further discu= ssion in the security considerations?=C2=A0 I think the authors would happi= ly add something if we can tell them what is needed, but I?m certainly not = the expert here.
>
> Ben.
>



--

Best regards,
Kathleen



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

Message: 6
Date: Thu, 3 Aug 2017 08:55:42 -0500
From: Ben Campbell <ben@nostrum.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, avtcore-chairs@ietf.org, Roni = Even
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <ron= i.even@huawei.com>, draft-ietf-avtcore-aria-srtp@ietf.org,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 avt@ietf.org
Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-avtcore-aria-srtp-10: (with COM= MENT)
Message-ID: <D2164284-D756-4193-AF5E-258FF8EFC09B@nostrum.com>
Content-Type: text/plain; charset=3Dutf-8


> On Aug 3, 2017, at 8:26 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com&g= t; wrote:
>
> Hi Ben,
>
> On Wed, Aug 2, 2017 at 11:15 PM, Ben Campbell <ben@nostrum.com> wrote:
>>
>>> On Aug 2, 2017, at 9:50 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.c= om> wrote:
>>>
>>> Hi Ben,
>>>
>>> Thanks for the quick response, inline.
>>>
>>> On Wed, Aug 2, 2017 at 10:36 PM, Ben Campbell <ben@nostrum.com> wrote:
>>>>
>>>>
>>>>
>>>>> On Aug 2, 2017, at 8:50 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmai= l.com> wrote:
>>>>> -------------------------------------------------= ---------------------
>>>>> COMMENT:
>>>>> -------------------------------------------------= ---------------------
>>>>>
>>>>> Although this is not a discuss, I think updated text w= ould be very helpful on
>>>>> the following two issues.
>>>>>
>>>>> I agree with the SecDir reviewer that there should be = more text around the
>>>>> short tag length in the security considerations sectio= n.=C2=A0 I don't see a
>>>>> response to that post though.
>>>>>
>>>>
>>>> Hi Kathleen,
>>>>
>>>> I think you are referring to Ben Laurie?s SecDir review of= 06, rather than his later review of 09. Is that correct? Version 9 removed= the GCM_8 modes. Or were you referring to something else?
>>>
>>> I am referring to Ben's review of -06, where he had the fo= llowing text:
>>>
>>> Thirdly, I am not familiar enough with SRTP to understand why = short
>>> authentication tags are needed, but in general its a bad idea,= so I
>>> feel the Security Considerations should explain more fully tha= n
>>> "Ciphersuites with short tag length may be
>>>=C2=A0 considered for specific application environments stated = in 7.5 of
>>>=C2=A0 [RFC3711], but the risk of weak authentication described= in
>>>=C2=A0 Section 9.5.1 of [RFC3711] should be taken into account.= "
>>>
>>> I don't see an update to this text to address his question= - providing
>>> additional information as to what should be "taken into a= ccount?.
>>
>> I had assumed his concern was about short tags in GCM mode, namely= the following:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0AEAD_ARIA_128_GCM_8
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0AEAD_ARIA_256_GCM_8
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0AEAD_ARIA_128_GCM_12
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0AEAD_ARIA_256_GCM_12
>>
>> These have all been removed as of version 09. Ben?s review of 09 m= ade no further mention of short tags.
>
> Thanks, but the text warning about them remains in the security
> considerations section.=C2=A0 Is it needed for some reason?
>

Ah, I get it?I thought you were asking for _more_ text :-). I think they pu= t that in as a result of the 06 review, but didn?t take it out when they re= moved those modes. I will verify that the authors don?t think the warning a= pplies to any of the remaining.

Ben.

> Kathleen
>
>>
>> Are there suites still in version 09 that you think need further d= iscussion in the security considerations?=C2=A0 I think the authors would h= appily add something if we can tell them what is needed, but I?m certainly = not the expert here.
>>
>> Ben.
>>
>
>
>
> --
>
> Best regards,
> Kathleen



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

Subject: Digest Footer

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt


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

End of avt Digest, Vol 160, Issue 2
***********************************

--001a114aaadc22756a0555df2952-- From nobody Mon Aug 7 01:01:00 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6379913217D; Mon, 7 Aug 2017 01:00: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 oKMco2dGlbrk; Mon, 7 Aug 2017 01:00:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F89F1293E1; Mon, 7 Aug 2017 01:00:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DMC38854; Mon, 07 Aug 2017 08:00:44 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 7 Aug 2017 08:59:46 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.170]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0301.000; Mon, 7 Aug 2017 15:58:47 +0800 From: Roni Even To: Ben Campbell CC: "avt@ietf.org" , Magnus Westerlund , The IESG Thread-Topic: New Version Notification for draft-ietf-avtcore-rfc5285-bis-13.txt Thread-Index: AQHTBk09aGipfo5cREyOWAv4T5019qJ4mTaA Date: Mon, 7 Aug 2017 07:58:46 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD7F19A0@DGGEMM506-MBX.china.huawei.com> References: <150079096276.31280.12592363692999578408.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD7EE876@DGGEMM506-MBX.china.huawei.com> <4868C682-0915-4AD0-868A-AB3E14E999DA@nostrum.com> <6E58094ECC8D8344914996DAD28F1CCD7EED0F@DGGEMM506-MBX.china.huawei.com> <7D454855-6211-484D-AA7E-37AF86CF7386@nostrum.com> In-Reply-To: <7D454855-6211-484D-AA7E-37AF86CF7386@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.51] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0205.59881E2D.0078, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.170, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0739a7d6dd42f71a758f7b587312c91d Archived-At: Subject: Re: [AVTCORE] New Version Notification for draft-ietf-avtcore-rfc5285-bis-13.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 08:00:51 -0000 SGkgQmVuLA0KQWRkZWQgc3VjaCBhIHNlbnRlbmNlIGluIHRoZSBuZXcgcmV2aXNpb24gLTE0DQpS b25pDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuIENhbXBiZWxs IFttYWlsdG86YmVuQG5vc3RydW0uY29tXQ0KPiBTZW50OiDXmdeV153CoNeTIDI2INeZ15XXnNeZ IDIwMTcgMjM6MjUNCj4gVG86IFJvbmkgRXZlbg0KPiBDYzogYXZ0QGlldGYub3JnOyBNYWdudXMg V2VzdGVybHVuZDsgVGhlIElFU0cNCj4gU3ViamVjdDogUmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtaWV0Zi1hdnRjb3JlLXJmYzUyODUtYmlzLQ0KPiAxMy50eHQNCj4gDQo+ IA0KPiA+IE9uIEp1bCAyNiwgMjAxNywgYXQgMTI6MDMgQU0sIFJvbmkgRXZlbiA8cm9uaS5ldmVu QGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+DQo+ID4gSEkgQmVuLA0KPiA+IEluYWN0aXZlIG1lYW5z IEkgc3VwcG9ydCB0aGUgZXh0ZW5zaW9uIGJ1dCB3b3VsZCBub3QgbGlrZSB0byBzZW5kIG9yDQo+ IHJlY2VpdmUgYXQgdGhlIG1vbWVudC4gTWF5IGRvIGl0IGluIGEgZnV0dXJlIG9mZmVyL2Fuc3dl ci4gVGhpcyBpcyB3aGVuIHRoZQ0KPiBhbnN3ZXJlciB1bmRlcnN0YW5kcyB0aGUgb2ZmZXJlZCBl eHRlbnNpb24uDQo+IA0KPiBIaSBSb25pLA0KPiANCj4gSSB0aGluayBpdCB3b3VsZCBiZSBoZWxw ZnVsIHRvIGFkZCBhIHNlbnRlbmNlIHRvIHRoYXQgZWZmZWN0IGZvciBlYWNoIGluc3RhbmNlLg0K PiANCj4gVGhhbmtzIQ0KPiANCj4gQmVuLg0KPiANCj4gDQo+ID4gUm9uaQ0KPiA+DQo+ID4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEJlbiBDYW1wYmVsbCBbbWFpbHRv OmJlbkBub3N0cnVtLmNvbV0NCj4gPj4gU2VudDog15nXldedINeSIDI1INeZ15XXnNeZIDIwMTcg MDA6NTINCj4gPj4gVG86IFJvbmkgRXZlbg0KPiA+PiBDYzogYXZ0QGlldGYub3JnOyBNYWdudXMg V2VzdGVybHVuZDsgVGhlIElFU0cNCj4gPj4gU3ViamVjdDogUmU6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3INCj4gPj4gZHJhZnQtaWV0Zi1hdnRjb3JlLXJmYzUyODUtYmlzLSAxMy50eHQN Cj4gPj4NCj4gPj4gSGkgUm9uaSwNCj4gPj4NCj4gPj4gSSBhZ3JlZSB0aGlzIGNvdmVycyB0aGUg SUVTRyBjb21tZW50cy4gSG93ZXZlciwgSSBhbSBjb25mdXNlZCBhYm91dA0KPiA+PiBzb21lIG9m IHRoZSBuZXcgdGV4dCBpbiBzZWN0aW9uIDcgYWJvdXQgYW4gYW5zd2VyZXIgbWFya2luZyBhbg0K PiA+PiBleHRlbnNpb24gYXMg4oCcaW5hY3RpdmXigJ0uIEkgYXNzdW1lIHRoZXNlIGFyZSBoZXJl IGluIHJlc3BvbnNlIHRvDQo+ID4+IEFsZXhleeKAmXMgcXVlc3Rpb25zIGFib3V0IHdoeSB0aGUg U0hPVUxEcyBhcmUgb25seSBTSE9VTERzLg0KPiA+Pg0KPiA+PiBJbiB0aGUgZmlyc3QgaW5zdGFu Y2U6DQo+ID4+DQo+ID4+ICAgIklmIGFuIGV4dGVuc2lvbiBpcyBtYXJrZWQgYXMgInNlbmRvbmx5 IiBhbmQgdGhlIGFuc3dlcmVyIGRlc2lyZXMgdG8NCj4gPj4gICByZWNlaXZlIGl0LCB0aGUgZXh0 ZW5zaW9uIE1VU1QgYmUgbWFya2VkIGFzICJyZWN2b25seSIgaW4gdGhlIFNEUA0KPiA+PiAgIGFu c3dlci4gIEFuIGFuc3dlcmVyIHRoYXQgaGFzIG5vIGRlc2lyZSB0byByZWNlaXZlIHRoZSBleHRl bnNpb24gb3INCj4gPj4gICBkb2VzIG5vdCB1bmRlcnN0YW5kIHRoZSBleHRlbnNpb24gU0hPVUxE IHJlbW92ZSBpdCBmcm9tIHRoZSBTRFANCj4gPj4gICBhbnN3ZXIuICBBbiBhbnN3ZXJlciBNQVkg d2FudCB0byByZXNwb25kIHRoYXQgaGUgc3VwcG9ydHMgdGhlDQo+ID4+ICAgZXh0ZW5zaW9uIGFu ZCBtYXkgdXNlIGl0IGluIHRoZSBmdXR1cmUgd2lsbCBtYXJrIHRoZSBleHRlbnNpb24gYXMNCj4g Pj4gICDigJxpbmFjdGl2ZeKAneKAnQ0KPiA+Pg0KPiA+PiBXaGF0IGRvZXMg4oCcd2lsbGluZyB0 byB1c2UgaXQgaW4gdGhlIGZ1dHVyZeKAnSBtZWFuIHRoYXQgaXMgZGlmZmVyZW50DQo+ID4+IHRo YW4ganVzdCBiZWluZyB3aWxsaW5nIHRvIHJlY2VpdmUgaXQsIHdoaWNoIGlzIGFscmVhZHkgY292 ZXJlZCBieQ0KPiA+PiBtYXJraW5nIGl0IGFzIOKAnHJlY3Zvbmx54oCdPyBEbyB3ZSBjb250ZW1w bGF0ZSB0aGF0IHRoZSBvZmZlcmVyIG1heSBhdA0KPiA+PiBzb21lIHBvaW50IGluIHRoZSBmdXR1 cmUgc2VuZCBhbiB1cGRhdGVkIG9mZmVyIG9yIGFuc3dlciB0aGF0IGNoYW5nZXMNCj4gdGhpcyB0 byDigJxyZWN2b25seeKAnT8NCj4gPj4NCj4gPj4gU2ltaWxhcmx5IGluIHRoZSBzZWNvbmQgaW5z dGFuY2U6DQo+ID4+DQo+ID4+ICBJZiBhbiBleHRlbnNpb24gaXMgbWFya2VkIGFzICJyZWN2b25s eSIgYW5kIHRoZSBhbnN3ZXJlciBkZXNpcmVzIHRvDQo+ID4+ICAgc2VuZCBpdCwgdGhlIGV4dGVu c2lvbiBNVVNUIGJlIG1hcmtlZCBhcyAic2VuZG9ubHkiIGluIHRoZSBTRFANCj4gPj4gICBhbnN3 ZXIuICBBbiBhbnN3ZXJlciB0aGF0IGhhcyBubyBkZXNpcmUgdG8sIG9yIGlzIHVuYWJsZSB0bywg c2VuZCB0aGUNCj4gPj4gICBleHRlbnNpb24gU0hPVUxEIHJlbW92ZSBpdCBmcm9tIHRoZSBTRFAg YW5zd2VyLiAgQW4gYW5zd2VyZXIgTUFZDQo+ID4+IHdhbnQNCj4gPj4gICB0byByZXNwb25kIHRo YXQgaGUgc3VwcG9ydCB0aGlzIGV4dGVuc2lvbiBhbmQgbWF5IHNlbmQgaW4gdGhlIGZ1dHVyZQ0K PiA+PiAgIG9yIHdpbGwgYmUgYWJsZSB0byByZWNlaXZlIGJ5IG1hcmtpbmcgdGhlIGV4dGVuc2lv biBhcyAiaW5hY3RpdmUiDQo+ID4+DQo+ID4+IOKApiBpcyB0aGUgYW5zd2VyIGV4cGVjdGVkIHRv IG1hcmsgdGhlIGV4dGVuc2lvbiBhcyDigJxzZW5kb25seeKAnSBhdCBzb21lDQo+ID4+IHBvaW50 IGluIHRoZSBmdXR1cmU/DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IElmIGl0IHR1cm5zIG91dCB0 aGF0IHRoZSBhZGRlZCB0ZXh0IGlzIHJvdWdobHkgY29ycmVjdCwgdGhlIHRleHQgaXMNCj4gPj4g c3RpbGwgY29uZnVzaW5nIGZyb20gYSBwdXJlIHNlbnRlbmNlIHN0cnVjdHVyZSBwZXJzcGVjdGl2 ZS4gSSB3b3VsZA0KPiA+PiBzdWdnZXN0IHRleHQsIGJ1dCB3ZSBwcm9iYWJseSBuZWVkIHRvIHJl c29sdmUgdGhlIGFib3ZlIHF1ZXN0aW9ucyBmaXJzdC4NCj4gPj4NCj4gPj4gVGhhbmtzIQ0KPiA+ Pg0KPiA+PiBCZW4uDQo+ID4+DQo+ID4+DQo+ID4+PiBPbiBKdWwgMjMsIDIwMTcsIGF0IDE6MjYg QU0sIFJvbmkgRXZlbiA8cm9uaS5ldmVuQGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+Pj4NCj4gPj4+ IEhpLA0KPiA+Pj4gSSBzdWJtaXR0ZWQgYSB2ZXJzaW9uIHRoYXQgSSBob3BlIGFkZHJlc3NlcyBh bGwgdGhlIGNvbW1lbnRzIGZyb20NCj4gPj4+IHRoZSBJRVNHDQo+ID4+IHJldmlldy4NCj4gPj4+ IFRoZSBtYWpvciBvcGVuIGlzc3VlIHdhcyB0aGUgY2F0ZWdvcnkgb2YgYWxsb3dlZC1taXggaW4g YnVuZGxlIGFuZA0KPiA+Pj4gYmFzZWQNCj4gPj4gb24gdGhlIFdHIHByZWZlcmVuY2UgaXQgaXMg bm93IElkZW50aWNhbC4NCj4gPj4+DQo+ID4+PiBUaGFua3MNCj4gPj4+IFJvbmkgRXZlbg0KPiA+ Pj4NCj4gPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+PiBGcm9tOiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+ID4+ PiBTZW50OiDXmdeV150g15AgMjMg15nXldec15kgMjAxNyAwOToyMw0KPiA+Pj4gVG86IEhhcmlr aXNoYW4gRGVzaW5lbmk7IEhhcmlLaXNoYW4gRGVzaW5lbmk7IFJvbmkgRXZlbjsgYXZ0Y29yZS0N Cj4gPj4gY2hhaXJzQGlldGYub3JnOyBEYXZpZCBTaW5nZXI7IFJvbmkgRXZlbg0KPiA+Pj4gU3Vi amVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+Pj4gZHJhZnQtaWV0Zi1hdnRj b3JlLXJmYzUyODUtYmlzLTEzLnR4dA0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBBIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQtaWV0Zi1hdnRjb3JlLXJmYzUyODUtYmlzLTEzLnR4dA0KPiA+Pj4gaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSb25pIEV2ZW4gYW5kIHBvc3RlZCB0byB0 aGUgSUVURg0KPiA+PiByZXBvc2l0b3J5Lg0KPiA+Pj4NCj4gPj4+IE5hbWU6CQlkcmFmdC1pZXRm LWF2dGNvcmUtcmZjNTI4NS1iaXMNCj4gPj4+IFJldmlzaW9uOgkxMw0KPiA+Pj4gVGl0bGU6CQlB IEdlbmVyYWwgTWVjaGFuaXNtIGZvciBSVFAgSGVhZGVyIEV4dGVuc2lvbnMNCj4gPj4+IERvY3Vt ZW50IGRhdGU6CTIwMTctMDctMjINCj4gPj4+IEdyb3VwOgkJYXZ0Y29yZQ0KPiA+Pj4gUGFnZXM6 CQkyNA0KPiA+Pj4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1pZXRmLWF2dGNvcmUtDQo+IHJmYzUyODUtDQo+ID4+IGJpcy0xMy50eHQN Cj4gPj4+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWF2dGNvcmUtcmZjNTI4NS0NCj4gYmlzLw0KPiA+Pj4gSHRtbGl6ZWQ6ICAgICAg IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWF2dGNvcmUtcmZjNTI4NS1i aXMtMTMNCj4gPj4+IEh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9odG1sL2RyYWZ0LWlldGYtYXZ0Y29yZS0NCj4gPj4gcmZjNTI4NS1iaXMtMTMNCj4gPj4+ IERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aWV0Zi1hdnRjb3JlLXJmYzUyODUtDQo+IGJpcy0NCj4gPj4gMTMNCj4gPj4+DQo+ID4+PiBBYnN0 cmFjdDoNCj4gPj4+ICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgZ2VuZXJhbCBtZWNoYW5pc20g dG8gdXNlIHRoZSBoZWFkZXINCj4gPj4+IGV4dGVuc2lvbiBmZWF0dXJlIG9mIFJUUCAodGhlIFJl YWwtVGltZSBUcmFuc3BvcnQgUHJvdG9jb2wpLiAgSXQNCj4gPj4+IHByb3ZpZGVzIHRoZSBvcHRp b24gdG8gdXNlIGEgc21hbGwgbnVtYmVyIG9mIHNtYWxsIGV4dGVuc2lvbnMgaW4NCj4gPj4+IGVh Y2ggIFJUUCBwYWNrZXQsIHdoZXJlIHRoZSB1bml2ZXJzZSBvZiBwb3NzaWJsZSBleHRlbnNpb25z IGlzIGxhcmdlDQo+ID4+PiBhbmQgIHJlZ2lzdHJhdGlvbiBpcyBkZS1jZW50cmFsaXplZC4gIFRo ZSBhY3R1YWwgZXh0ZW5zaW9ucyBpbiB1c2UNCj4gPj4+IGluIGEgIHNlc3Npb24gYXJlIHNpZ25h bGVkIGluIHRoZSBzZXR1cCBpbmZvcm1hdGlvbiBmb3IgdGhhdA0KPiA+Pj4gc2Vzc2lvbi4gIFRo aXMgIGRvY3VtZW50IG9ic29sZXRlcyBSRkM1Mjg1Lg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+ Pj4NCj4gPj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0KPiB0b29scy5pZXRmLm9yZy4NCj4gPj4+ DQo+ID4+PiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiA+Pj4NCj4gPg0KDQo= From nobody Mon Aug 7 12:52:05 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA9F131D38; Mon, 7 Aug 2017 12:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 X05xKzkXYLZf; Mon, 7 Aug 2017 12:52:03 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2604C131CEC; Mon, 7 Aug 2017 12:52:03 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v77Jq067009383 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 7 Aug 2017 14:52:01 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Mon, 7 Aug 2017 14:52:00 -0500 Cc: avtcore-chairs@ietf.org, draft-ietf-avtcore-aria-srtp@ietf.org, The IESG , avt@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3B1A7FF4-22D0-4988-AB8C-0DC64E020C0B@nostrum.com> References: <150172505031.5791.14553211399724965332.idtracker@ietfa.amsl.com> <084BEE4A-1241-42C6-BD39-36F11792ABB4@nostrum.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on draft-ietf-avtcore-aria-srtp-10: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 19:52:04 -0000 > On Aug 3, 2017, at 8:55 AM, Ben Campbell wrote: >=20 >>>> I am referring to Ben's review of -06, where he had the following = text: >>>>=20 >>>> Thirdly, I am not familiar enough with SRTP to understand why short >>>> authentication tags are needed, but in general its a bad idea, so I >>>> feel the Security Considerations should explain more fully than >>>> "Ciphersuites with short tag length may be >>>> considered for specific application environments stated in 7.5 of >>>> [RFC3711], but the risk of weak authentication described in >>>> Section 9.5.1 of [RFC3711] should be taken into account." >>>>=20 >>>> I don't see an update to this text to address his question - = providing >>>> additional information as to what should be "taken into account=E2=80= =9D. >>>=20 >>> I had assumed his concern was about short tags in GCM mode, namely = the following: >>>=20 >>> AEAD_ARIA_128_GCM_8 >>> AEAD_ARIA_256_GCM_8 >>> AEAD_ARIA_128_GCM_12 >>> AEAD_ARIA_256_GCM_12 >>>=20 >>> These have all been removed as of version 09. Ben=E2=80=99s review = of 09 made no further mention of short tags. >>=20 >> Thanks, but the text warning about them remains in the security >> considerations section. Is it needed for some reason? >>=20 >=20 > Ah, I get it=E2=80=94I thought you were asking for _more_ text :-). I = think they put that in as a result of the 06 review, but didn=E2=80=99t = take it out when they removed those modes. I will verify that the = authors don=E2=80=99t think the warning applies to any of the remaining. >=20 In further discussion with the authors, I learned that they think the = guidance still applies, due to the HMAC_SHA1_32 suites that are still in = the document. (There are currently 3, but this will become 2 once they = remove the SRTP_ARIA_192 suites due to other comments from Ekr.) But on doing a little more research, I am not sure I understand the = concern with the security consideration language (quoted here for = convenience): "Ciphersuites with short tag length may be considered for specific application environments stated in 7.5 of [RFC3711], but the risk of weak authentication described in Section 9.5.1 of [RFC3711] should be taken into account" I have suggested that the authors clarify which suites they consider to = have =E2=80=9Cshort=E2=80=9D tags. But otherwise, It references 3711 = section 7.5, which talks about some specific scenarios where short = authentication tags may be needed, and section 9.5 which talks about = specific risks of null or weak authentication. Implementors need to = consider those things and make a choice. It=E2=80=99s not clear to me = what additional guidance would be helpful here=E2=80=94do you have = suggestions? Thanks! Ben.= From nobody Mon Aug 7 13:26:18 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2CE132256; Mon, 7 Aug 2017 13:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 ZLwnzVHUYNkf; Mon, 7 Aug 2017 13:26:07 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8FC1B131D37; Mon, 7 Aug 2017 13:26:07 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v77KPw7S017610 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 7 Aug 2017 15:25:59 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD7F19A0@DGGEMM506-MBX.china.huawei.com> Date: Mon, 7 Aug 2017 15:25:57 -0500 Cc: "avt@ietf.org" , Magnus Westerlund , The IESG Content-Transfer-Encoding: quoted-printable Message-Id: <2CCB6C91-0D9E-4558-A417-4BC83D43D42F@nostrum.com> References: <150079096276.31280.12592363692999578408.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD7EE876@DGGEMM506-MBX.china.huawei.com> <4868C682-0915-4AD0-868A-AB3E14E999DA@nostrum.com> <6E58094ECC8D8344914996DAD28F1CCD7EED0F@DGGEMM506-MBX.china.huawei.com> <7D454855-6211-484D-AA7E-37AF86CF7386@nostrum.com> <6E58094ECC8D8344914996DAD28F1CCD7F19A0@DGGEMM506-MBX.china.huawei.com> To: Roni Even X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [AVTCORE] New Version Notification for draft-ietf-avtcore-rfc5285-bis-13.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 20:26:10 -0000 Hi Roni, This version looks good. I approved it for publication. It=E2=80=99s now = in the hands of the RFC Editor. Thanks! Ben. > On Aug 7, 2017, at 2:58 AM, Roni Even wrote: >=20 > Hi Ben, > Added such a sentence in the new revision -14 > Roni >=20 >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: =D7=99=D7=95=D7=9D =D7=93 26 =D7=99=D7=95=D7=9C=D7=99 2017 = 23:25 >> To: Roni Even >> Cc: avt@ietf.org; Magnus Westerlund; The IESG >> Subject: Re: New Version Notification for = draft-ietf-avtcore-rfc5285-bis- >> 13.txt >>=20 >>=20 >>> On Jul 26, 2017, at 12:03 AM, Roni Even = wrote: >>>=20 >>> HI Ben, >>> Inactive means I support the extension but would not like to send or >> receive at the moment. May do it in a future offer/answer. This is = when the >> answerer understands the offered extension. >>=20 >> Hi Roni, >>=20 >> I think it would be helpful to add a sentence to that effect for each = instance. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >>=20 >>> Roni >>>=20 >>>> -----Original Message----- >>>> From: Ben Campbell [mailto:ben@nostrum.com] >>>> Sent: =D7=99=D7=95=D7=9D =D7=92 25 =D7=99=D7=95=D7=9C=D7=99 2017 = 00:52 >>>> To: Roni Even >>>> Cc: avt@ietf.org; Magnus Westerlund; The IESG >>>> Subject: Re: New Version Notification for >>>> draft-ietf-avtcore-rfc5285-bis- 13.txt >>>>=20 >>>> Hi Roni, >>>>=20 >>>> I agree this covers the IESG comments. However, I am confused about >>>> some of the new text in section 7 about an answerer marking an >>>> extension as =E2=80=9Cinactive=E2=80=9D. I assume these are here in = response to >>>> Alexey=E2=80=99s questions about why the SHOULDs are only SHOULDs. >>>>=20 >>>> In the first instance: >>>>=20 >>>> "If an extension is marked as "sendonly" and the answerer desires = to >>>> receive it, the extension MUST be marked as "recvonly" in the SDP >>>> answer. An answerer that has no desire to receive the extension = or >>>> does not understand the extension SHOULD remove it from the SDP >>>> answer. An answerer MAY want to respond that he supports the >>>> extension and may use it in the future will mark the extension as >>>> =E2=80=9Cinactive=E2=80=9D=E2=80=9D >>>>=20 >>>> What does =E2=80=9Cwilling to use it in the future=E2=80=9D mean = that is different >>>> than just being willing to receive it, which is already covered by >>>> marking it as =E2=80=9Crecvonly=E2=80=9D? Do we contemplate that = the offerer may at >>>> some point in the future send an updated offer or answer that = changes >> this to =E2=80=9Crecvonly=E2=80=9D? >>>>=20 >>>> Similarly in the second instance: >>>>=20 >>>> If an extension is marked as "recvonly" and the answerer desires to >>>> send it, the extension MUST be marked as "sendonly" in the SDP >>>> answer. An answerer that has no desire to, or is unable to, send = the >>>> extension SHOULD remove it from the SDP answer. An answerer MAY >>>> want >>>> to respond that he support this extension and may send in the = future >>>> or will be able to receive by marking the extension as "inactive" >>>>=20 >>>> =E2=80=A6 is the answer expected to mark the extension as = =E2=80=9Csendonly=E2=80=9D at some >>>> point in the future? >>>>=20 >>>>=20 >>>>=20 >>>> If it turns out that the added text is roughly correct, the text is >>>> still confusing from a pure sentence structure perspective. I would >>>> suggest text, but we probably need to resolve the above questions = first. >>>>=20 >>>> Thanks! >>>>=20 >>>> Ben. >>>>=20 >>>>=20 >>>>> On Jul 23, 2017, at 1:26 AM, Roni Even = wrote: >>>>>=20 >>>>> Hi, >>>>> I submitted a version that I hope addresses all the comments from >>>>> the IESG >>>> review. >>>>> The major open issue was the category of allowed-mix in bundle and >>>>> based >>>> on the WG preference it is now Identical. >>>>>=20 >>>>> Thanks >>>>> Roni Even >>>>>=20 >>>>> -----Original Message----- >>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>> Sent: =D7=99=D7=95=D7=9D =D7=90 23 =D7=99=D7=95=D7=9C=D7=99 2017 = 09:23 >>>>> To: Harikishan Desineni; HariKishan Desineni; Roni Even; avtcore- >>>> chairs@ietf.org; David Singer; Roni Even >>>>> Subject: New Version Notification for >>>>> draft-ietf-avtcore-rfc5285-bis-13.txt >>>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-ietf-avtcore-rfc5285-bis-13.txt >>>>> has been successfully submitted by Roni Even and posted to the = IETF >>>> repository. >>>>>=20 >>>>> Name: draft-ietf-avtcore-rfc5285-bis >>>>> Revision: 13 >>>>> Title: A General Mechanism for RTP Header Extensions >>>>> Document date: 2017-07-22 >>>>> Group: avtcore >>>>> Pages: 24 >>>>> URL: = https://www.ietf.org/internet-drafts/draft-ietf-avtcore- >> rfc5285- >>>> bis-13.txt >>>>> Status: = https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285- >> bis/ >>>>> Htmlized: = https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis-13 >>>>> Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-avtcore- >>>> rfc5285-bis-13 >>>>> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-rfc5285- >> bis- >>>> 13 >>>>>=20 >>>>> Abstract: >>>>> This document provides a general mechanism to use the header >>>>> extension feature of RTP (the Real-Time Transport Protocol). It >>>>> provides the option to use a small number of small extensions in >>>>> each RTP packet, where the universe of possible extensions is = large >>>>> and registration is de-centralized. The actual extensions in use >>>>> in a session are signaled in the setup information for that >>>>> session. This document obsoletes RFC5285. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> The IETF Secretariat >>>>>=20 >>>=20 >=20 From nobody Mon Aug 7 13:44:51 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BBE132484; Mon, 7 Aug 2017 13:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 n4_CdKRVjgrB; Mon, 7 Aug 2017 13:44:41 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 4995E132480; Mon, 7 Aug 2017 13:44:41 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id t86so5869987pfe.2; Mon, 07 Aug 2017 13:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iFiE5GYv7Yo4aDmyqhP2JHibi25mhbqMlU3jMUDNR5U=; b=JpxCgd5d7zyUne38Lz8a4IM6NHJWOlvMZaw+nzU0cE2WWFFjx2TZ2kTLjxgs33uZjd 1eVj2BtoR5rthMKZxdBt5k++zCl+rZzh97yvIxa7/Du6UO5id0+jJYBcxxH2fYN3dLLn uwG22YIWwVRNjyMzZlG9iezRIwmXs+dO+PVyIITAePWIedV74+e48Aj8zv5rtepDFSar sjqQZViuoemCs1sbAG7/w3wpgTPYKxfDhpYvp9EDwmn7u4p1s7zMyv+RAmA/JHdOYyPF 1/kPZeugOzDdcZjkTKtKAqDnQwmx1YRcz0AO8aXTPtBP94cPf1U/kMfZVqky9zUCavgY 7CUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=iFiE5GYv7Yo4aDmyqhP2JHibi25mhbqMlU3jMUDNR5U=; b=q0ubE7/KPFNWy1B4SN6KnfQM9Na/K52oyVssAecAKGQN0XgxyHsRrktpAjGM7oSIwD oeTYqgGOsM3+miQaZAKl0BjEX3jF5xnk5wrqhNOMVC+H7Fjcu+Rs6dYP5eqXK8WjywjD VkB99PXAX717HZLQzSMQHRh2PqHe7Q2ahBOe/8jdQrAdsj7v9uZFXDPhQGGw7eKabkgG XB9CzWEmUdISO/J7EGfHKw1n3Um87QAlf+zXbxtQdAbeZ4DzLbz/udysR59OChpUkDMv mPgPFh3rsTVi4FdHvSiKr4HQ20cNHLDrXjsSOTrCzA1DhKED3hOlbkNWeyLGc7dbEEmx XV5g== X-Gm-Message-State: AHYfb5gtoBUqn0jwSy053iMeLj1L1zlVJPTYFwudJFA956eCvo/gknIX AeUsb33YRdZ8oglsukYxrWC26BWPT4xe X-Received: by 10.84.229.13 with SMTP id b13mr1999224plk.352.1502138680594; Mon, 07 Aug 2017 13:44:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.144.1 with HTTP; Mon, 7 Aug 2017 13:44:00 -0700 (PDT) In-Reply-To: <3B1A7FF4-22D0-4988-AB8C-0DC64E020C0B@nostrum.com> References: <150172505031.5791.14553211399724965332.idtracker@ietfa.amsl.com> <084BEE4A-1241-42C6-BD39-36F11792ABB4@nostrum.com> <3B1A7FF4-22D0-4988-AB8C-0DC64E020C0B@nostrum.com> From: Kathleen Moriarty Date: Mon, 7 Aug 2017 16:44:00 -0400 Message-ID: To: Ben Campbell Cc: avtcore-chairs@ietf.org, draft-ietf-avtcore-aria-srtp@ietf.org, The IESG , avt@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on draft-ietf-avtcore-aria-srtp-10: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 20:44:43 -0000 Hi Ben, On Mon, Aug 7, 2017 at 3:52 PM, Ben Campbell wrote: > >> On Aug 3, 2017, at 8:55 AM, Ben Campbell wrote: >> >>>>> I am referring to Ben's review of -06, where he had the following tex= t: >>>>> >>>>> Thirdly, I am not familiar enough with SRTP to understand why short >>>>> authentication tags are needed, but in general its a bad idea, so I >>>>> feel the Security Considerations should explain more fully than >>>>> "Ciphersuites with short tag length may be >>>>> considered for specific application environments stated in 7.5 of >>>>> [RFC3711], but the risk of weak authentication described in >>>>> Section 9.5.1 of [RFC3711] should be taken into account." >>>>> >>>>> I don't see an update to this text to address his question - providin= g >>>>> additional information as to what should be "taken into account=E2=80= =9D. >>>> >>>> I had assumed his concern was about short tags in GCM mode, namely the= following: >>>> >>>> AEAD_ARIA_128_GCM_8 >>>> AEAD_ARIA_256_GCM_8 >>>> AEAD_ARIA_128_GCM_12 >>>> AEAD_ARIA_256_GCM_12 >>>> >>>> These have all been removed as of version 09. Ben=E2=80=99s review of = 09 made no further mention of short tags. >>> >>> Thanks, but the text warning about them remains in the security >>> considerations section. Is it needed for some reason? >>> >> >> Ah, I get it=E2=80=94I thought you were asking for _more_ text :-). I th= ink they put that in as a result of the 06 review, but didn=E2=80=99t take = it out when they removed those modes. I will verify that the authors don=E2= =80=99t think the warning applies to any of the remaining. >> > > In further discussion with the authors, I learned that they think the gui= dance still applies, due to the HMAC_SHA1_32 suites that are still in the d= ocument. (There are currently 3, but this will become 2 once they remove th= e SRTP_ARIA_192 suites due to other comments from Ekr.) > > But on doing a little more research, I am not sure I understand the conce= rn with the security consideration language (quoted here for convenience): > > "Ciphersuites with short tag length may be > considered for specific application environments stated in 7.5 of > [RFC3711], but the risk of weak authentication described in > Section 9.5.1 of [RFC3711] should be taken into account" > > I have suggested that the authors clarify which suites they consider to h= ave =E2=80=9Cshort=E2=80=9D tags. But otherwise, It references 3711 sectio= n 7.5, which talks about some specific scenarios where short authentication= tags may be needed, and section 9.5 which talks about specific risks of nu= ll or weak authentication. Implementors need to consider those things and m= ake a choice. It=E2=80=99s not clear to me what additional guidance would b= e helpful here=E2=80=94do you have suggestions? I just looked at 3711 and agree with what you said, section 9.5 mostly talks about weak or null authentication, with only the following said about short tags (*coupled with weak authentication): Under this condition, the size of the authentication tag MUST ensure that only a negligible fraction of the packets passed to the RTP application by the SRTP receiver can be forgeries. This fraction is negligible when an adversary, if given control of the forged packets, is not able to make a significant impact on the output of the RTP application (see the example of Section 7.5). The draft in question says the above should be taken into account, the original question was how? Looking back at it, I'm wondering if instead of saying "taken into account", the use of short tags should be discouraged to NOT RECOMMENDED. Can the RTP application detect the forgeries or the SRTP receiver? Is this asking that if weak authentication tags are used, some sort of risk mitigation is performed to reduce the number of forgeries? It doesn't say how though, so I'm asking if it should be discouraged or if there is some mechanism to do this when short tags are in use. Thank you, Kathleen > > Thanks! > > Ben. --=20 Best regards, Kathleen From nobody Mon Aug 7 14:01:45 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D67C128AA1; Mon, 7 Aug 2017 14:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 azaE_Ovy60wY; Mon, 7 Aug 2017 14:01:41 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 891E812009C; Mon, 7 Aug 2017 14:01:41 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v77L1dHP026166 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 7 Aug 2017 16:01:40 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Mon, 7 Aug 2017 16:01:38 -0500 Cc: avtcore-chairs@ietf.org, draft-ietf-avtcore-aria-srtp@ietf.org, The IESG , avt@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5A5203CD-3F8F-4C08-9B3E-B25F97F56B23@nostrum.com> References: <150172505031.5791.14553211399724965332.idtracker@ietfa.amsl.com> <084BEE4A-1241-42C6-BD39-36F11792ABB4@nostrum.com> <3B1A7FF4-22D0-4988-AB8C-0DC64E020C0B@nostrum.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on draft-ietf-avtcore-aria-srtp-10: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 21:01:45 -0000 > On Aug 7, 2017, at 3:44 PM, Kathleen Moriarty = wrote: >=20 > Hi Ben, >=20 > On Mon, Aug 7, 2017 at 3:52 PM, Ben Campbell wrote: >>=20 >>> On Aug 3, 2017, at 8:55 AM, Ben Campbell wrote: >>>=20 >>>>>> I am referring to Ben's review of -06, where he had the following = text: >>>>>>=20 >>>>>> Thirdly, I am not familiar enough with SRTP to understand why = short >>>>>> authentication tags are needed, but in general its a bad idea, so = I >>>>>> feel the Security Considerations should explain more fully than >>>>>> "Ciphersuites with short tag length may be >>>>>> considered for specific application environments stated in 7.5 of >>>>>> [RFC3711], but the risk of weak authentication described in >>>>>> Section 9.5.1 of [RFC3711] should be taken into account." >>>>>>=20 >>>>>> I don't see an update to this text to address his question - = providing >>>>>> additional information as to what should be "taken into = account=E2=80=9D. >>>>>=20 >>>>> I had assumed his concern was about short tags in GCM mode, namely = the following: >>>>>=20 >>>>> AEAD_ARIA_128_GCM_8 >>>>> AEAD_ARIA_256_GCM_8 >>>>> AEAD_ARIA_128_GCM_12 >>>>> AEAD_ARIA_256_GCM_12 >>>>>=20 >>>>> These have all been removed as of version 09. Ben=E2=80=99s review = of 09 made no further mention of short tags. >>>>=20 >>>> Thanks, but the text warning about them remains in the security >>>> considerations section. Is it needed for some reason? >>>>=20 >>>=20 >>> Ah, I get it=E2=80=94I thought you were asking for _more_ text :-). = I think they put that in as a result of the 06 review, but didn=E2=80=99t = take it out when they removed those modes. I will verify that the = authors don=E2=80=99t think the warning applies to any of the remaining. >>>=20 >>=20 >> In further discussion with the authors, I learned that they think the = guidance still applies, due to the HMAC_SHA1_32 suites that are still in = the document. (There are currently 3, but this will become 2 once they = remove the SRTP_ARIA_192 suites due to other comments from Ekr.) >>=20 >> But on doing a little more research, I am not sure I understand the = concern with the security consideration language (quoted here for = convenience): >>=20 >> "Ciphersuites with short tag length may be >> considered for specific application environments stated in 7.5 of >> [RFC3711], but the risk of weak authentication described in >> Section 9.5.1 of [RFC3711] should be taken into account" >>=20 >> I have suggested that the authors clarify which suites they consider = to have =E2=80=9Cshort=E2=80=9D tags. But otherwise, It references 3711 = section 7.5, which talks about some specific scenarios where short = authentication tags may be needed, and section 9.5 which talks about = specific risks of null or weak authentication. Implementors need to = consider those things and make a choice. It=E2=80=99s not clear to me = what additional guidance would be helpful here=E2=80=94do you have = suggestions? >=20 > I just looked at 3711 and agree with what you said, section 9.5 mostly > talks about weak or null authentication, with only the following said > about short tags (*coupled with weak authentication): >=20 > Under this condition, the size of the > authentication tag MUST ensure that only a negligible fraction of = the > packets passed to the RTP application by the SRTP receiver can be > forgeries. This fraction is negligible when an adversary, if given > control of the forged packets, is not able to make a significant > impact on the output of the RTP application (see the example of > Section 7.5). >=20 > The draft in question says the above should be taken into account, the > original question was how? Looking back at it, I'm wondering if > instead of saying "taken into account", the use of short tags should > be discouraged to NOT RECOMMENDED. Can the RTP application detect the > forgeries or the SRTP receiver? Is this asking that if weak > authentication tags are used, some sort of risk mitigation is > performed to reduce the number of forgeries? It doesn't say how > though, so I'm asking if it should be discouraged or if there is some > mechanism to do this when short tags are in use. Well, I think the authentication tag _is_ the way SRTP prevents = forgeries :-) A =E2=80=9CSHOULD NOT=E2=80=9D or =E2=80=9CNOT RECOMMENDED=E2=80=9D = might make sense, but let me probe a little more: Section 7.5 of 3711 is specifically about short authentication tags. It = lists a couple of situations where full length tags can be problematic. Section 9.5 starts out talking about =E2=80=9Cnull or weak=E2=80=9D = authentication. But most of the section seems to be more about = =E2=80=9Cnull=E2=80=9D rather than =E2=80=9Cweak=E2=80=9D = authentication. This section is not specifically about short = authentication tags, so it=E2=80=99s not clear to me if short tags used = with HMAC_SHA1 suites would be considered =E2=80=9Cweak=E2=80=9D for the = purposes of that section. They at least provide _some_ forgery = protection, just maybe not as much as one might like. Would it make sense to say something to the effect of the following = (with possible additional wordsmithing): =E2=80=9CThis document includes ciphersuites with authentication tags of = length less than 80 bits. These suites MAY be used for certain = application contexts where longer authentication tags may be = undesirable, for example, those mentioned in [RFC 3711] section 7.5. = Otherwise, Short authentication tags SHOULD NOT be used, since may = reduce authentication strength. See [RFC 3711] section 9.5 for a = discussion of risks related to weak authentication in SRTP.=E2=80=9D Thanks! Ben. >=20 > Thank you, > Kathleen >=20 >>=20 >> Thanks! >>=20 >> Ben. >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen From nobody Mon Aug 7 14:40:33 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667791243F6; Mon, 7 Aug 2017 14:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 gMXIf0EelVkU; Mon, 7 Aug 2017 14:40:29 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 DFB881200F3; Mon, 7 Aug 2017 14:40:28 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id s6so10393725qtc.1; Mon, 07 Aug 2017 14:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WBeeR8bq6lrba6sauZRv9AKKiSCdwIM2FzKuw/ApYVY=; b=VE2jsMhtyzmtxYkFZ7NNNRwOuiR9LYot74NRC+LZ+X7lGUYDqB0ffEgpfJF9Xq5DGw AkImuKbAoVt3d5Q5d5To+IOAyKsIYTFnZILP8JliA9En8VDfDfQLo+rq+ITQQlbnsMwg 7sRNPweNL9F8M4SIrKBTKUAT/3l8HSFQ8Fw5G+SFUJMa23M1Ti1P0vN1sgRdaklHpqMl BL0J7M30soYIa1h0pS3PCN1maBjqe7lffMTBb5Joczm6oiyzKfNiSI9tGAHQn2vuDyh6 iSlo8jFB/FfAMcnxWJtP4wUhkRNnQWxjUqj7uHAtJT6EPJw4pgGFKlGCOkHUoBRH7l63 +GRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WBeeR8bq6lrba6sauZRv9AKKiSCdwIM2FzKuw/ApYVY=; b=GEOmlzTqKmbnYf1Ezh+1D5IzywSWKLcKSK/KeJulNrHNow7pYnHMKWV07vfY8O0aj8 97cVxQSBGvggy2HRdX5Fyc59MdLNZkBQg5MW/z6eZbD4JDS5cjQf8ZZ2tFMIZqrjOAWq I1YWpqyFM5BVIQ3xQxSKk1o+xkV92b/B9Vuxl1aqfdYIo2F8C7HMNDUalMHPgrljX5Fu tZ+34dLkEMvbIcKWeT5bgE3Iavcscwx9ONme1QMXDum5PP2Sfw39a1CHXfgLec9XxvnX pYklLoCk6Sk/8L3NYwl63tkjZzgxlE95kjLfjLrzjwAjyJT3W9x0MsW575YBf1RPoJTz LgAg== X-Gm-Message-State: AHYfb5gNgbeAZmTjcZ47EUyHkRGRyi9GHgUDKjYgDFI8N9RLVbgUZ+1h ApXjuneTU6oDcoFpeuU= X-Received: by 10.237.43.197 with SMTP id e63mr2910151qtd.86.1502142027868; Mon, 07 Aug 2017 14:40:27 -0700 (PDT) Received: from [192.168.1.13] (209-6-124-204.s3530.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id b68sm5682723qkc.88.2017.08.07.14.40.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 14:40:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: <5A5203CD-3F8F-4C08-9B3E-B25F97F56B23@nostrum.com> Date: Mon, 7 Aug 2017 17:40:26 -0400 Cc: avtcore-chairs@ietf.org, draft-ietf-avtcore-aria-srtp@ietf.org, The IESG , avt@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5C6D5E91-944E-4881-BF25-91988E720857@gmail.com> References: <150172505031.5791.14553211399724965332.idtracker@ietfa.amsl.com> <084BEE4A-1241-42C6-BD39-36F11792ABB4@nostrum.com> <3B1A7FF4-22D0-4988-AB8C-0DC64E020C0B@nostrum.com> <5A5203CD-3F8F-4C08-9B3E-B25F97F56B23@nostrum.com> To: Ben Campbell Archived-At: Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on draft-ietf-avtcore-aria-srtp-10: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 21:40:31 -0000 Thanks, Ben. Sent from my iPhone > On Aug 7, 2017, at 5:01 PM, Ben Campbell wrote: >=20 >=20 >> On Aug 7, 2017, at 3:44 PM, Kathleen Moriarty wrote: >>=20 >> Hi Ben, >>=20 >>> On Mon, Aug 7, 2017 at 3:52 PM, Ben Campbell wrote: >>>=20 >>>> On Aug 3, 2017, at 8:55 AM, Ben Campbell wrote: >>>>=20 >>>>>>> I am referring to Ben's review of -06, where he had the following te= xt: >>>>>>>=20 >>>>>>> Thirdly, I am not familiar enough with SRTP to understand why short >>>>>>> authentication tags are needed, but in general its a bad idea, so I >>>>>>> feel the Security Considerations should explain more fully than >>>>>>> "Ciphersuites with short tag length may be >>>>>>> considered for specific application environments stated in 7.5 of >>>>>>> [RFC3711], but the risk of weak authentication described in >>>>>>> Section 9.5.1 of [RFC3711] should be taken into account." >>>>>>>=20 >>>>>>> I don't see an update to this text to address his question - providi= ng >>>>>>> additional information as to what should be "taken into account=E2=80= =9D. >>>>>>=20 >>>>>> I had assumed his concern was about short tags in GCM mode, namely th= e following: >>>>>>=20 >>>>>> AEAD_ARIA_128_GCM_8 >>>>>> AEAD_ARIA_256_GCM_8 >>>>>> AEAD_ARIA_128_GCM_12 >>>>>> AEAD_ARIA_256_GCM_12 >>>>>>=20 >>>>>> These have all been removed as of version 09. Ben=E2=80=99s review of= 09 made no further mention of short tags. >>>>>=20 >>>>> Thanks, but the text warning about them remains in the security >>>>> considerations section. Is it needed for some reason? >>>>>=20 >>>>=20 >>>> Ah, I get it=E2=80=94I thought you were asking for _more_ text :-). I t= hink they put that in as a result of the 06 review, but didn=E2=80=99t take i= t out when they removed those modes. I will verify that the authors don=E2=80= =99t think the warning applies to any of the remaining. >>>>=20 >>>=20 >>> In further discussion with the authors, I learned that they think the gu= idance still applies, due to the HMAC_SHA1_32 suites that are still in the d= ocument. (There are currently 3, but this will become 2 once they remove the= SRTP_ARIA_192 suites due to other comments from Ekr.) >>>=20 >>> But on doing a little more research, I am not sure I understand the conc= ern with the security consideration language (quoted here for convenience): >>>=20 >>> "Ciphersuites with short tag length may be >>> considered for specific application environments stated in 7.5 of >>> [RFC3711], but the risk of weak authentication described in >>> Section 9.5.1 of [RFC3711] should be taken into account" >>>=20 >>> I have suggested that the authors clarify which suites they consider to h= ave =E2=80=9Cshort=E2=80=9D tags. But otherwise, It references 3711 section= 7.5, which talks about some specific scenarios where short authentication t= ags may be needed, and section 9.5 which talks about specific risks of null o= r weak authentication. Implementors need to consider those things and make a= choice. It=E2=80=99s not clear to me what additional guidance would be help= ful here=E2=80=94do you have suggestions? >>=20 >> I just looked at 3711 and agree with what you said, section 9.5 mostly >> talks about weak or null authentication, with only the following said >> about short tags (*coupled with weak authentication): >>=20 >> Under this condition, the size of the >> authentication tag MUST ensure that only a negligible fraction of the >> packets passed to the RTP application by the SRTP receiver can be >> forgeries. This fraction is negligible when an adversary, if given >> control of the forged packets, is not able to make a significant >> impact on the output of the RTP application (see the example of >> Section 7.5). >>=20 >> The draft in question says the above should be taken into account, the >> original question was how? Looking back at it, I'm wondering if >> instead of saying "taken into account", the use of short tags should >> be discouraged to NOT RECOMMENDED. Can the RTP application detect the >> forgeries or the SRTP receiver? Is this asking that if weak >> authentication tags are used, some sort of risk mitigation is >> performed to reduce the number of forgeries? It doesn't say how >> though, so I'm asking if it should be discouraged or if there is some >> mechanism to do this when short tags are in use. >=20 > Well, I think the authentication tag _is_ the way SRTP prevents forgeries := -) >=20 > A =E2=80=9CSHOULD NOT=E2=80=9D or =E2=80=9CNOT RECOMMENDED=E2=80=9D might m= ake sense, but let me probe a little more: >=20 > Section 7.5 of 3711 is specifically about short authentication tags. It li= sts a couple of situations where full length tags can be problematic. >=20 > Section 9.5 starts out talking about =E2=80=9Cnull or weak=E2=80=9D authen= tication. But most of the section seems to be more about =E2=80=9Cnull=E2=80= =9D rather than =E2=80=9Cweak=E2=80=9D authentication. This section is not s= pecifically about short authentication tags, so it=E2=80=99s not clear to me= if short tags used with HMAC_SHA1 suites would be considered =E2=80=9Cweak=E2= =80=9D for the purposes of that section. They at least provide _some_ forger= y protection, just maybe not as much as one might like. >=20 > Would it make sense to say something to the effect of the following (with p= ossible additional wordsmithing): >=20 > =E2=80=9CThis document includes ciphersuites with authentication tags of l= ength less than 80 bits. These suites MAY be used for certain application co= ntexts where longer authentication tags may be undesirable, for example, tho= se mentioned in [RFC 3711] section 7.5. Otherwise, Short authentication tags= SHOULD NOT be used, since may reduce authentication strength. See [RFC 3711= ] section 9.5 for a discussion of risks related to weak authentication in SR= TP.=E2=80=9D That's much better and provides guidance. Thank you! Kathleen=20 >=20 > Thanks! >=20 > Ben. >=20 >>=20 >> Thank you, >> Kathleen >>=20 >>>=20 >>> Thanks! >>>=20 >>> Ben. >>=20 >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >=20 From nobody Mon Aug 7 14:47:39 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B7A12009C; Mon, 7 Aug 2017 14:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 iP6faqL4TFFF; Mon, 7 Aug 2017 14:47:30 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5234B1200F3; Mon, 7 Aug 2017 14:47:30 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v77LlSR2037106 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 7 Aug 2017 16:47:28 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <5C6D5E91-944E-4881-BF25-91988E720857@gmail.com> Date: Mon, 7 Aug 2017 16:47:27 -0500 Cc: avtcore-chairs@ietf.org, draft-ietf-avtcore-aria-srtp@ietf.org, The IESG , avt@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150172505031.5791.14553211399724965332.idtracker@ietfa.amsl.com> <084BEE4A-1241-42C6-BD39-36F11792ABB4@nostrum.com> <3B1A7FF4-22D0-4988-AB8C-0DC64E020C0B@nostrum.com> <5A5203CD-3F8F-4C08-9B3E-B25F97F56B23@nostrum.com> <5C6D5E91-944E-4881-BF25-91988E720857@gmail.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on draft-ietf-avtcore-aria-srtp-10: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 21:47:32 -0000 Authors, please see below: > On Aug 7, 2017, at 4:40 PM, Kathleen Moriarty = wrote: >=20 >>>>=20 >>>> In further discussion with the authors, I learned that they think = the guidance still applies, due to the HMAC_SHA1_32 suites that are = still in the document. (There are currently 3, but this will become 2 = once they remove the SRTP_ARIA_192 suites due to other comments from = Ekr.) >>>>=20 >>>> But on doing a little more research, I am not sure I understand the = concern with the security consideration language (quoted here for = convenience): >>>>=20 >>>> "Ciphersuites with short tag length may be >>>> considered for specific application environments stated in 7.5 of >>>> [RFC3711], but the risk of weak authentication described in >>>> Section 9.5.1 of [RFC3711] should be taken into account" >>>>=20 >>>> I have suggested that the authors clarify which suites they = consider to have =E2=80=9Cshort=E2=80=9D tags. But otherwise, It = references 3711 section 7.5, which talks about some specific scenarios = where short authentication tags may be needed, and section 9.5 which = talks about specific risks of null or weak authentication. Implementors = need to consider those things and make a choice. It=E2=80=99s not clear = to me what additional guidance would be helpful here=E2=80=94do you have = suggestions? >>>=20 >>> I just looked at 3711 and agree with what you said, section 9.5 = mostly >>> talks about weak or null authentication, with only the following = said >>> about short tags (*coupled with weak authentication): >>>=20 >>> Under this condition, the size of the >>> authentication tag MUST ensure that only a negligible fraction of = the >>> packets passed to the RTP application by the SRTP receiver can be >>> forgeries. This fraction is negligible when an adversary, if given >>> control of the forged packets, is not able to make a significant >>> impact on the output of the RTP application (see the example of >>> Section 7.5). >>>=20 >>> The draft in question says the above should be taken into account, = the >>> original question was how? Looking back at it, I'm wondering if >>> instead of saying "taken into account", the use of short tags should >>> be discouraged to NOT RECOMMENDED. Can the RTP application detect = the >>> forgeries or the SRTP receiver? Is this asking that if weak >>> authentication tags are used, some sort of risk mitigation is >>> performed to reduce the number of forgeries? It doesn't say how >>> though, so I'm asking if it should be discouraged or if there is = some >>> mechanism to do this when short tags are in use. >>=20 >> Well, I think the authentication tag _is_ the way SRTP prevents = forgeries :-) >>=20 >> A =E2=80=9CSHOULD NOT=E2=80=9D or =E2=80=9CNOT RECOMMENDED=E2=80=9D = might make sense, but let me probe a little more: >>=20 >> Section 7.5 of 3711 is specifically about short authentication tags. = It lists a couple of situations where full length tags can be = problematic. >>=20 >> Section 9.5 starts out talking about =E2=80=9Cnull or weak=E2=80=9D = authentication. But most of the section seems to be more about = =E2=80=9Cnull=E2=80=9D rather than =E2=80=9Cweak=E2=80=9D = authentication. This section is not specifically about short = authentication tags, so it=E2=80=99s not clear to me if short tags used = with HMAC_SHA1 suites would be considered =E2=80=9Cweak=E2=80=9D for the = purposes of that section. They at least provide _some_ forgery = protection, just maybe not as much as one might like. >>=20 >> Would it make sense to say something to the effect of the following = (with possible additional wordsmithing): >>=20 >> =E2=80=9CThis document includes ciphersuites with authentication tags = of length less than 80 bits. These suites MAY be used for certain = application contexts where longer authentication tags may be = undesirable, for example, those mentioned in [RFC 3711] section 7.5. = Otherwise, Short authentication tags SHOULD NOT be used, since may = reduce authentication strength. See [RFC 3711] section 9.5 for a = discussion of risks related to weak authentication in SRTP.=E2=80=9D > That's much better and provides guidance. Thank you! > Kathleen=20 >=20 Authors: Would that proposed text work for you? Thanks! Ben. From nobody Mon Aug 7 15:28:36 2017 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E4E129D9D; Mon, 7 Aug 2017 15:28:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Cc: avtcore-chairs@ietf.org, ben@nostrum.com, magnus.westerlund@ericsson.com, draft-ietf-avtcore-rfc5285-bis@ietf.org, avt@ietf.org, Magnus Westerlund , The IESG , rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150214489822.12379.292211275981007926.idtracker@ietfa.amsl.com> Date: Mon, 07 Aug 2017 15:28:18 -0700 Archived-At: Subject: [AVTCORE] Protocol Action: 'A General Mechanism for RTP Header Extensions' to Proposed Standard (draft-ietf-avtcore-rfc5285-bis-14.txt) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 22:28:18 -0000 The IESG has approved the following document: - 'A General Mechanism for RTP Header Extensions' (draft-ietf-avtcore-rfc5285-bis-14.txt) as Proposed Standard This document is the product of the Audio/Video Transport Core Maintenance Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/ Technical Summary This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. The document obsoletes RFC5285 Working Group Summary This document has had no major discussions. There has been some discussion concerning RTP protocol level and the higher applications dependency on header extension elements and the possibility of removing them. Document Quality This is an update of the previous document to address some issues learned in the usage and further specification of RTP header extensions following RFC5285. The amount of review has been sufficient but not great. Personnel The document shepherd is Magnus Westerlund and the responsible AD is Ben Campbell. From nobody Mon Aug 7 21:52:55 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F379D1243F3; Mon, 7 Aug 2017 21:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 7dtKQ_hg57vw; Mon, 7 Aug 2017 21:52:47 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 854C3126CD6; Mon, 7 Aug 2017 21:52:42 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v784qYaf038715 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 7 Aug 2017 23:52:35 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <000401d31001$1d432df0$57c989d0$@nsr.re.kr> Date: Mon, 7 Aug 2017 23:52:34 -0500 Cc: Kathleen Moriarty , avtcore-chairs@ietf.org, draft-ietf-avtcore-aria-srtp@ietf.org, The IESG , IETF AVTCore WG , Roni Even Content-Transfer-Encoding: quoted-printable Message-Id: <959EFAA1-C1EE-4A0F-AB3A-024CEA5E3180@nostrum.com> References: <150172505031.5791.14553211399724965332.idtracker@ietfa.amsl.com> <084BEE4A-1241-42C6-BD39-36F11792ABB4@nostrum.com> <3B1A7FF4-22D0-4988-AB8C-0DC64E020C0B@nostrum.com> <5A5203CD-3F8F-4C08-9B3E-B25F97F56B23@nostrum.com> <5C6D5E91-944E-4881-BF25-91988E720857@gmail.com> <000401d31001$1d432df0$57c989d0$@nsr.re.kr> To: Woo-Hwan Kim X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on draft-ietf-avtcore-aria-srtp-10: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 04:52:48 -0000 (Adding the draft shepherd) That all looks good. Please submit a new version at your convenience. Thanks! Ben. > On Aug 7, 2017, at 11:45 PM, Woo-Hwan Kim wrote: >=20 > Your suggestion seems to be fine. > We will add and edit some sentence. >=20 > (Add) > At the time of publication of this document, SRTP recommends HMAC-SHA1 = as the default and mandatory-to-implement MAC algorithm. All currently = registered SRTP crypto suites except the GCM based ones use HMAC-SHA1 as = their HMAC algorithm to provide message authentication. Due to security = concerns with SHA-1 [RFC6194], the IETF is gradually moving away from = SHA-1 and towards stronger hash algorithms such as SHA-2 or SHA-3 = families. For SRTP, however, SHA-1 is only used in the calculation of an = HMAC, and no security issue is known for this usage at the time of this = publication. >=20 > (Edit) > OLD: > Protection profiles with short tag length may be considered for = specific application environments stated in Section 7.5 of [RFC3711], = but the risk of weak authentication described in Section 9.5.1 of = [RFC3711] should be taken into account. >=20 > NEW: > This document includes crypto suites with authentication tags of = length less than 80 bits. These suites MAY be used for certain = application contexts where longer authentication tags may be = undesirable, for example, those mentioned in [RFC 3711] section 7.5. = Otherwise, Short authentication tags SHOULD NOT be used, since may = reduce authentication strength. See [RFC 3711] section 9.5 for a = discussion of risks related to weak authentication in SRTP. >=20 > Additionally, we will remove two ARIA-192 crypto suites. This reflects = the comments of Eric Rescorla and Ben Campbell that it would be better = to match the key sizes of CTR and GCM crypto suites unless the 192-bit = key size is already in use or likely to be in use soon. >=20 > Thanks for all of discussions and suggestions. >=20 > Sincerely, Woo-Hwan Kim >=20 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com]=20 > Sent: Tuesday, August 08, 2017 6:47 AM > To: Kathleen Moriarty > Cc: avtcore-chairs@ietf.org; draft-ietf-avtcore-aria-srtp@ietf.org; = The IESG ; avt@ietf.org > Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on = draft-ietf-avtcore-aria-srtp-10: (with COMMENT) >=20 > Authors, please see below: >=20 >> On Aug 7, 2017, at 4:40 PM, Kathleen Moriarty = wrote: >>=20 >>>>>=20 >>>>> In further discussion with the authors, I learned that they think=20= >>>>> the guidance still applies, due to the HMAC_SHA1_32 suites that = are=20 >>>>> still in the document. (There are currently 3, but this will = become=20 >>>>> 2 once they remove the SRTP_ARIA_192 suites due to other comments=20= >>>>> from Ekr.) >>>>>=20 >>>>> But on doing a little more research, I am not sure I understand = the concern with the security consideration language (quoted here for = convenience): >>>>>=20 >>>>> "Ciphersuites with short tag length may be considered for specific=20= >>>>> application environments stated in 7.5 of [RFC3711], but the risk=20= >>>>> of weak authentication described in Section 9.5.1 of [RFC3711]=20 >>>>> should be taken into account" >>>>>=20 >>>>> I have suggested that the authors clarify which suites they = consider to have =E2=80=9Cshort=E2=80=9D tags. But otherwise, It = references 3711 section 7.5, which talks about some specific scenarios = where short authentication tags may be needed, and section 9.5 which = talks about specific risks of null or weak authentication. Implementors = need to consider those things and make a choice. It=E2=80=99s not clear = to me what additional guidance would be helpful here=E2=80=94do you have = suggestions? >>>>=20 >>>> I just looked at 3711 and agree with what you said, section 9.5=20 >>>> mostly talks about weak or null authentication, with only the=20 >>>> following said about short tags (*coupled with weak = authentication): >>>>=20 >>>> Under this condition, the size of the authentication tag MUST = ensure=20 >>>> that only a negligible fraction of the packets passed to the RTP=20 >>>> application by the SRTP receiver can be forgeries. This fraction = is=20 >>>> negligible when an adversary, if given control of the forged=20 >>>> packets, is not able to make a significant impact on the output of=20= >>>> the RTP application (see the example of Section 7.5). >>>>=20 >>>> The draft in question says the above should be taken into account,=20= >>>> the original question was how? Looking back at it, I'm wondering = if=20 >>>> instead of saying "taken into account", the use of short tags = should=20 >>>> be discouraged to NOT RECOMMENDED. Can the RTP application detect=20= >>>> the forgeries or the SRTP receiver? Is this asking that if weak=20 >>>> authentication tags are used, some sort of risk mitigation is=20 >>>> performed to reduce the number of forgeries? It doesn't say how=20 >>>> though, so I'm asking if it should be discouraged or if there is=20 >>>> some mechanism to do this when short tags are in use. >>>=20 >>> Well, I think the authentication tag _is_ the way SRTP prevents=20 >>> forgeries :-) >>>=20 >>> A =E2=80=9CSHOULD NOT=E2=80=9D or =E2=80=9CNOT RECOMMENDED=E2=80=9D = might make sense, but let me probe a little more: >>>=20 >>> Section 7.5 of 3711 is specifically about short authentication tags. = It lists a couple of situations where full length tags can be = problematic. >>>=20 >>> Section 9.5 starts out talking about =E2=80=9Cnull or weak=E2=80=9D = authentication. But most of the section seems to be more about = =E2=80=9Cnull=E2=80=9D rather than =E2=80=9Cweak=E2=80=9D = authentication. This section is not specifically about short = authentication tags, so it=E2=80=99s not clear to me if short tags used = with HMAC_SHA1 suites would be considered =E2=80=9Cweak=E2=80=9D for the = purposes of that section. They at least provide _some_ forgery = protection, just maybe not as much as one might like. >>>=20 >>> Would it make sense to say something to the effect of the following = (with possible additional wordsmithing): >>>=20 >>> =E2=80=9CThis document includes ciphersuites with authentication = tags of length less than 80 bits. These suites MAY be used for certain = application contexts where longer authentication tags may be = undesirable, for example, those mentioned in [RFC 3711] section 7.5. = Otherwise, Short authentication tags SHOULD NOT be used, since may = reduce authentication strength. See [RFC 3711] section 9.5 for a = discussion of risks related to weak authentication in SRTP.=E2=80=9D >> That's much better and provides guidance. Thank you! >> Kathleen >>=20 >=20 > Authors: Would that proposed text work for you? >=20 > Thanks! >=20 > Ben. >=20 >=20 From nobody Mon Aug 7 21:53:21 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79051127201 for ; Mon, 7 Aug 2017 21:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.392 X-Spam-Level: X-Spam-Status: No, score=0.392 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.499, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 wvcHLiEywtcs for ; Mon, 7 Aug 2017 21:53:19 -0700 (PDT) Received: from spam.nsr.re.kr (unknown [210.104.33.65]) by ietfa.amsl.com (Postfix) with ESMTP id D7542126CD8 for ; Mon, 7 Aug 2017 21:53:07 -0700 (PDT) Received: from unknown (HELO nsr.re.kr) (210.104.33.70) by 210.104.33.65 with ESMTP; 8 Aug 2017 13:44:53 +0900 X-Original-SENDERIP: 210.104.33.70 X-Original-MAILFROM: whkim5@nsr.re.kr Received: from 192.168.155.183 ([192.168.155.183]) by mail.nsr.re.kr (Crinity Message Backbone-7.0.1) with SMTP ID 651; Tue, 8 Aug 2017 13:45:36 +0900 (KST) From: Woo-Hwan Kim To: 'Ben Campbell' , 'Kathleen Moriarty' Cc: avtcore-chairs@ietf.org, draft-ietf-avtcore-aria-srtp@ietf.org, 'The IESG' , avt@ietf.org References: <150172505031.5791.14553211399724965332.idtracker@ietfa.amsl.com> <084BEE4A-1241-42C6-BD39-36F11792ABB4@nostrum.com> <3B1A7FF4-22D0-4988-AB8C-0DC64E020C0B@nostrum.com> <5A5203CD-3F8F-4C08-9B3E-B25F97F56B23@nostrum.com> <5C6D5E91-944E-4881-BF25-91988E720857@gmail.com> In-Reply-To: Date: Tue, 8 Aug 2017 13:45:09 +0900 Message-ID: <000401d31001$1d432df0$57c989d0$@nsr.re.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQG1NE3fAF7Mt3UkqtJMocJduGpArAGGPKWKAWkpFMwCrlP5nAIWrvHqAkPHSOQCNQOGpAH39WPIAi2geuMCL4CmkwHLMgshohMigxA= Content-Language: ko Archived-At: Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on draft-ietf-avtcore-aria-srtp-10: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 04:53:20 -0000 Your suggestion seems to be fine. We will add and edit some sentence. (Add) At the time of publication of this document, SRTP recommends HMAC-SHA1 = as the default and mandatory-to-implement MAC algorithm. All currently = registered SRTP crypto suites except the GCM based ones use HMAC-SHA1 as = their HMAC algorithm to provide message authentication. Due to security = concerns with SHA-1 [RFC6194], the IETF is gradually moving away from = SHA-1 and towards stronger hash algorithms such as SHA-2 or SHA-3 = families. For SRTP, however, SHA-1 is only used in the calculation of an = HMAC, and no security issue is known for this usage at the time of this = publication. (Edit) OLD: Protection profiles with short tag length may be considered for specific = application environments stated in Section 7.5 of [RFC3711], but the = risk of weak authentication described in Section 9.5.1 of [RFC3711] = should be taken into account. NEW: This document includes crypto suites with authentication tags of length = less than 80 bits. These suites MAY be used for certain application = contexts where longer authentication tags may be undesirable, for = example, those mentioned in [RFC 3711] section 7.5. Otherwise, Short = authentication tags SHOULD NOT be used, since may reduce authentication = strength. See [RFC 3711] section 9.5 for a discussion of risks related = to weak authentication in SRTP. Additionally, we will remove two ARIA-192 crypto suites. This reflects = the comments of Eric Rescorla and Ben Campbell that it would be better = to match the key sizes of CTR and GCM crypto suites unless the 192-bit = key size is already in use or likely to be in use soon. Thanks for all of discussions and suggestions. Sincerely, Woo-Hwan Kim -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Tuesday, August 08, 2017 6:47 AM To: Kathleen Moriarty Cc: avtcore-chairs@ietf.org; draft-ietf-avtcore-aria-srtp@ietf.org; The = IESG ; avt@ietf.org Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on = draft-ietf-avtcore-aria-srtp-10: (with COMMENT) Authors, please see below: > On Aug 7, 2017, at 4:40 PM, Kathleen Moriarty = wrote: >=20 >>>>=20 >>>> In further discussion with the authors, I learned that they think=20 >>>> the guidance still applies, due to the HMAC_SHA1_32 suites that are = >>>> still in the document. (There are currently 3, but this will become = >>>> 2 once they remove the SRTP_ARIA_192 suites due to other comments=20 >>>> from Ekr.) >>>>=20 >>>> But on doing a little more research, I am not sure I understand the = concern with the security consideration language (quoted here for = convenience): >>>>=20 >>>> "Ciphersuites with short tag length may be considered for specific=20 >>>> application environments stated in 7.5 of [RFC3711], but the risk=20 >>>> of weak authentication described in Section 9.5.1 of [RFC3711]=20 >>>> should be taken into account" >>>>=20 >>>> I have suggested that the authors clarify which suites they = consider to have =E2=80=9Cshort=E2=80=9D tags. But otherwise, It = references 3711 section 7.5, which talks about some specific scenarios = where short authentication tags may be needed, and section 9.5 which = talks about specific risks of null or weak authentication. Implementors = need to consider those things and make a choice. It=E2=80=99s not clear = to me what additional guidance would be helpful here=E2=80=94do you have = suggestions? >>>=20 >>> I just looked at 3711 and agree with what you said, section 9.5=20 >>> mostly talks about weak or null authentication, with only the=20 >>> following said about short tags (*coupled with weak authentication): >>>=20 >>> Under this condition, the size of the authentication tag MUST ensure = >>> that only a negligible fraction of the packets passed to the RTP=20 >>> application by the SRTP receiver can be forgeries. This fraction is = >>> negligible when an adversary, if given control of the forged=20 >>> packets, is not able to make a significant impact on the output of=20 >>> the RTP application (see the example of Section 7.5). >>>=20 >>> The draft in question says the above should be taken into account,=20 >>> the original question was how? Looking back at it, I'm wondering if = >>> instead of saying "taken into account", the use of short tags should = >>> be discouraged to NOT RECOMMENDED. Can the RTP application detect=20 >>> the forgeries or the SRTP receiver? Is this asking that if weak=20 >>> authentication tags are used, some sort of risk mitigation is=20 >>> performed to reduce the number of forgeries? It doesn't say how=20 >>> though, so I'm asking if it should be discouraged or if there is=20 >>> some mechanism to do this when short tags are in use. >>=20 >> Well, I think the authentication tag _is_ the way SRTP prevents=20 >> forgeries :-) >>=20 >> A =E2=80=9CSHOULD NOT=E2=80=9D or =E2=80=9CNOT RECOMMENDED=E2=80=9D = might make sense, but let me probe a little more: >>=20 >> Section 7.5 of 3711 is specifically about short authentication tags. = It lists a couple of situations where full length tags can be = problematic. >>=20 >> Section 9.5 starts out talking about =E2=80=9Cnull or weak=E2=80=9D = authentication. But most of the section seems to be more about = =E2=80=9Cnull=E2=80=9D rather than =E2=80=9Cweak=E2=80=9D = authentication. This section is not specifically about short = authentication tags, so it=E2=80=99s not clear to me if short tags used = with HMAC_SHA1 suites would be considered =E2=80=9Cweak=E2=80=9D for the = purposes of that section. They at least provide _some_ forgery = protection, just maybe not as much as one might like. >>=20 >> Would it make sense to say something to the effect of the following = (with possible additional wordsmithing): >>=20 >> =E2=80=9CThis document includes ciphersuites with authentication tags = of length less than 80 bits. These suites MAY be used for certain = application contexts where longer authentication tags may be = undesirable, for example, those mentioned in [RFC 3711] section 7.5. = Otherwise, Short authentication tags SHOULD NOT be used, since may = reduce authentication strength. See [RFC 3711] section 9.5 for a = discussion of risks related to weak authentication in SRTP.=E2=80=9D > That's much better and provides guidance. Thank you! > Kathleen >=20 Authors: Would that proposed text work for you? Thanks! Ben. From nobody Tue Aug 8 03:27:45 2017 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E561321BA; Tue, 8 Aug 2017 03:27:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150218805664.12399.2992664109473016783@ietfa.amsl.com> Date: Tue, 08 Aug 2017 03:27:36 -0700 Archived-At: Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-aria-srtp-11.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 10:27:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance WG of the IETF. Title : The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP) Authors : Woo-Hwan Kim Jungkeun Lee Je-Hong Park Daesung Kwon Dong-Chan Kim Filename : draft-ietf-avtcore-aria-srtp-11.txt Pages : 19 Date : 2017-08-08 Abstract: This document defines the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP). It details two modes of operation (CTR, GCM) and the SRTP Key Derivation Functions for ARIA. Additionally, this document defines DTLS-SRTP protection profiles and MIKEY parameter sets for the use with ARIA. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-avtcore-aria-srtp-11 https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-aria-srtp-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-aria-srtp-11 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 Aug 8 07:26:26 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F392A13250D; Tue, 8 Aug 2017 07:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 PQkEq5tfAYfw; Tue, 8 Aug 2017 07:26:22 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e: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 BCA1D132543; Tue, 8 Aug 2017 07:26:22 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id u185so15527776pgb.1; Tue, 08 Aug 2017 07:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=genKounIZtMZdwiUfYcvppvbqwu4UWyS3hD4Eh7yeb4=; b=FhWz1agb+4LrnnUm9i5nFSMD9IlvDpTixFwh40mmKofZn0n7KPzngavR1dKIlJRpri wde8Obhsba2XslnTqnL9kxYXx/8HRJFPualGLD8hQpu7A/uFHU4VxjH99rEN0wqJk64n PdXTitbY1AefZM1YK8Wb0vQGWZ9AV922dSAwkzUb4rXQNFYj7N348gYRJi3rDf4dW63K QqhDh7Kqtqxa2RwGcJBHY03U0l57j/2Ym9ODr+YYI8EPNR/0TYgW6f6yFzIQVY2rDSv6 qPS457T5WeVgDMiYYF6NDnZUarsfzvUyq6fYNxSlyrbGG8oNqwMma9We2wdTrMxvosu6 vBhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=genKounIZtMZdwiUfYcvppvbqwu4UWyS3hD4Eh7yeb4=; b=i0Usn0KnYlqKVIDW/9PxKy/fFqljH/ID976DMhR1i77ee+nv59qG/DrHLtBboZVvL5 IznpcCfjk7xo5uUk3h2JpcCU4XcYQTJeC56pxKA3WF29kQytXCxMOrhQy7czU8uq3V3j YgkYtLQ1FZ8wVz7ylFulDnj/2dDNrfRbJQyNBN5j034CEYVmd6ICWO2A/yN0TFioEpSJ d62gDlv9qHc/KhwGTaeWgAyy43YV1AB0gvtbX2gEnk3+WK0FWviT6XOjHnoCK459nVUY 9tPbSA5CbXO7r0zmsPdTGgVSbNdiwaNU/vKDpZOoM/bDdEy/28RIcwX7Bq8QTPlnYLNl p/0A== X-Gm-Message-State: AHYfb5jP7xZKNMwvgVRAs6jMhxD3dERsxSa3DxOyhQ+/JNhOy82zfXrc 3tAWiWtE4+Jb+Ut3xZ0Sk1NAbGIBaw== X-Received: by 10.84.129.103 with SMTP id 94mr4829145plb.63.1502202381156; Tue, 08 Aug 2017 07:26:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.144.1 with HTTP; Tue, 8 Aug 2017 07:25:40 -0700 (PDT) In-Reply-To: <959EFAA1-C1EE-4A0F-AB3A-024CEA5E3180@nostrum.com> References: <150172505031.5791.14553211399724965332.idtracker@ietfa.amsl.com> <084BEE4A-1241-42C6-BD39-36F11792ABB4@nostrum.com> <3B1A7FF4-22D0-4988-AB8C-0DC64E020C0B@nostrum.com> <5A5203CD-3F8F-4C08-9B3E-B25F97F56B23@nostrum.com> <5C6D5E91-944E-4881-BF25-91988E720857@gmail.com> <000401d31001$1d432df0$57c989d0$@nsr.re.kr> <959EFAA1-C1EE-4A0F-AB3A-024CEA5E3180@nostrum.com> From: Kathleen Moriarty Date: Tue, 8 Aug 2017 10:25:40 -0400 Message-ID: To: Ben Campbell Cc: Woo-Hwan Kim , avtcore-chairs@ietf.org, draft-ietf-avtcore-aria-srtp@ietf.org, The IESG , IETF AVTCore WG , Roni Even Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on draft-ietf-avtcore-aria-srtp-10: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 14:26:25 -0000 Thank you, all! On Tue, Aug 8, 2017 at 12:52 AM, Ben Campbell wrote: > (Adding the draft shepherd) > > That all looks good. Please submit a new version at your convenience. > > Thanks! > > Ben. > >> On Aug 7, 2017, at 11:45 PM, Woo-Hwan Kim wrote: >> >> Your suggestion seems to be fine. >> We will add and edit some sentence. >> >> (Add) >> At the time of publication of this document, SRTP recommends HMAC-SHA1 a= s the default and mandatory-to-implement MAC algorithm. All currently regis= tered SRTP crypto suites except the GCM based ones use HMAC-SHA1 as their H= MAC algorithm to provide message authentication. Due to security concerns w= ith SHA-1 [RFC6194], the IETF is gradually moving away from SHA-1 and towar= ds stronger hash algorithms such as SHA-2 or SHA-3 families. For SRTP, howe= ver, SHA-1 is only used in the calculation of an HMAC, and no security issu= e is known for this usage at the time of this publication. >> >> (Edit) >> OLD: >> Protection profiles with short tag length may be considered for specific= application environments stated in Section 7.5 of [RFC3711], but the risk = of weak authentication described in Section 9.5.1 of [RFC3711] should be ta= ken into account. >> >> NEW: >> This document includes crypto suites with authentication tags of length = less than 80 bits. These suites MAY be used for certain application context= s where longer authentication tags may be undesirable, for example, those m= entioned in [RFC 3711] section 7.5. Otherwise, Short authentication tags SH= OULD NOT be used, since may reduce authentication strength. See [RFC 3711] = section 9.5 for a discussion of risks related to weak authentication in SRT= P. >> >> Additionally, we will remove two ARIA-192 crypto suites. This reflects t= he comments of Eric Rescorla and Ben Campbell that it would be better to ma= tch the key sizes of CTR and GCM crypto suites unless the 192-bit key size = is already in use or likely to be in use soon. >> >> Thanks for all of discussions and suggestions. >> >> Sincerely, Woo-Hwan Kim >> >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Tuesday, August 08, 2017 6:47 AM >> To: Kathleen Moriarty >> Cc: avtcore-chairs@ietf.org; draft-ietf-avtcore-aria-srtp@ietf.org; The = IESG ; avt@ietf.org >> Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on draft-ietf-av= tcore-aria-srtp-10: (with COMMENT) >> >> Authors, please see below: >> >>> On Aug 7, 2017, at 4:40 PM, Kathleen Moriarty wrote: >>> >>>>>> >>>>>> In further discussion with the authors, I learned that they think >>>>>> the guidance still applies, due to the HMAC_SHA1_32 suites that are >>>>>> still in the document. (There are currently 3, but this will become >>>>>> 2 once they remove the SRTP_ARIA_192 suites due to other comments >>>>>> from Ekr.) >>>>>> >>>>>> But on doing a little more research, I am not sure I understand the = concern with the security consideration language (quoted here for convenien= ce): >>>>>> >>>>>> "Ciphersuites with short tag length may be considered for specific >>>>>> application environments stated in 7.5 of [RFC3711], but the risk >>>>>> of weak authentication described in Section 9.5.1 of [RFC3711] >>>>>> should be taken into account" >>>>>> >>>>>> I have suggested that the authors clarify which suites they consider= to have =E2=80=9Cshort=E2=80=9D tags. But otherwise, It references 3711 s= ection 7.5, which talks about some specific scenarios where short authentic= ation tags may be needed, and section 9.5 which talks about specific risks = of null or weak authentication. Implementors need to consider those things = and make a choice. It=E2=80=99s not clear to me what additional guidance wo= uld be helpful here=E2=80=94do you have suggestions? >>>>> >>>>> I just looked at 3711 and agree with what you said, section 9.5 >>>>> mostly talks about weak or null authentication, with only the >>>>> following said about short tags (*coupled with weak authentication): >>>>> >>>>> Under this condition, the size of the authentication tag MUST ensure >>>>> that only a negligible fraction of the packets passed to the RTP >>>>> application by the SRTP receiver can be forgeries. This fraction is >>>>> negligible when an adversary, if given control of the forged >>>>> packets, is not able to make a significant impact on the output of >>>>> the RTP application (see the example of Section 7.5). >>>>> >>>>> The draft in question says the above should be taken into account, >>>>> the original question was how? Looking back at it, I'm wondering if >>>>> instead of saying "taken into account", the use of short tags should >>>>> be discouraged to NOT RECOMMENDED. Can the RTP application detect >>>>> the forgeries or the SRTP receiver? Is this asking that if weak >>>>> authentication tags are used, some sort of risk mitigation is >>>>> performed to reduce the number of forgeries? It doesn't say how >>>>> though, so I'm asking if it should be discouraged or if there is >>>>> some mechanism to do this when short tags are in use. >>>> >>>> Well, I think the authentication tag _is_ the way SRTP prevents >>>> forgeries :-) >>>> >>>> A =E2=80=9CSHOULD NOT=E2=80=9D or =E2=80=9CNOT RECOMMENDED=E2=80=9D mi= ght make sense, but let me probe a little more: >>>> >>>> Section 7.5 of 3711 is specifically about short authentication tags. I= t lists a couple of situations where full length tags can be problematic. >>>> >>>> Section 9.5 starts out talking about =E2=80=9Cnull or weak=E2=80=9D au= thentication. But most of the section seems to be more about =E2=80=9Cnull= =E2=80=9D rather than =E2=80=9Cweak=E2=80=9D authentication. This section i= s not specifically about short authentication tags, so it=E2=80=99s not cle= ar to me if short tags used with HMAC_SHA1 suites would be considered =E2= =80=9Cweak=E2=80=9D for the purposes of that section. They at least provide= _some_ forgery protection, just maybe not as much as one might like. >>>> >>>> Would it make sense to say something to the effect of the following (w= ith possible additional wordsmithing): >>>> >>>> =E2=80=9CThis document includes ciphersuites with authentication tags = of length less than 80 bits. These suites MAY be used for certain applicati= on contexts where longer authentication tags may be undesirable, for exampl= e, those mentioned in [RFC 3711] section 7.5. Otherwise, Short authenticati= on tags SHOULD NOT be used, since may reduce authentication strength. See [= RFC 3711] section 9.5 for a discussion of risks related to weak authenticat= ion in SRTP.=E2=80=9D >>> That's much better and provides guidance. Thank you! >>> Kathleen >>> >> >> Authors: Would that proposed text work for you? >> >> Thanks! >> >> Ben. >> >> > --=20 Best regards, Kathleen From nobody Wed Aug 9 06:44:06 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0111320B5; Wed, 9 Aug 2017 06:43:58 -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 8aLpRjti1599; Wed, 9 Aug 2017 06:43:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60F60131EB2; Wed, 9 Aug 2017 06:43:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DTA90744; Wed, 09 Aug 2017 13:43:53 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 9 Aug 2017 14:43:51 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.170]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0301.000; Wed, 9 Aug 2017 21:43:29 +0800 From: Roni Even To: Christer Holmberg , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Taylor Brandstetter CC: "rtcweb@ietf.org" , "avt@ietf.org" Thread-Topic: [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? Thread-Index: AQHTD4ZeWfNzICrgU0mNlPq2aeHenKJ47jTA///hPQCAADoWAIAAAq8AgAAizfCAAjDagIAAlitggAAUltA= Date: Wed, 9 Aug 2017 13:43:29 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD7F2006@DGGEMM506-MBX.china.huawei.com> References: <7594FB04B1934943A5C02806D1A2204B4CCB17B5@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCB2093@ESESSMB109.ericsson.se> <6E58094ECC8D8344914996DAD28F1CCD7F1F02@DGGEMM506-MBX.china.huawei.com> <7594FB04B1934943A5C02806D1A2204B4CCB5B07@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CCB5B07@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.51] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.598B1199.00FA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.170, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: df59ab82d8b2f00f103ccea64c6b2d4e Archived-At: Subject: Re: [AVTCORE] [rtcweb] Replacing a=extmap mapping in re-offer, is it legal? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 13:43:58 -0000 SGkgQ2hyaXN0ZXIsDQpJbmxpbmUsIGNjIGF2dGNvcmUgc2luY2UgaXQgaXMgYXZ0Y29yZSBkb2N1 bWVudCAuDQpMb29rIGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWF2 dGNvcmUtcmZjNTI4NS1iaXMtMTQjc2VjdGlvbi03IA0KUm9uaQ0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IENocmlzdGVyIEhvbG1iZXJnIFttYWlsdG86Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tXQ0KPiBTZW50OiDXmdeV153CoNeTIDA5INeQ15XXkteV16HX mCAyMDE3IDE1OjI3DQo+IFRvOiBSb25pIEV2ZW47IEnDsWFraSBCYXogQ2FzdGlsbG87IFRheWxv ciBCcmFuZHN0ZXR0ZXINCj4gQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW3J0 Y3dlYl0gUmVwbGFjaW5nIGE9ZXh0bWFwIG1hcHBpbmcgaW4gcmUtb2ZmZXIsIGlzIGl0IGxlZ2Fs Pw0KPiANCj4gSGksDQo+IA0KPiA+PiBUYXlsb3IncyBleHBsYW5hdGlvbiBtYWtlcyBzZW5zZS4g QnV0LCBpbiB0aGlzIGNhc2U6DQo+ID4+DQo+ID4+IDEpIFJlLXVzaW5nIHRoZSBzYW1lIHZhbHVl IHdpdGggYSBuZXcgbWFwcGluZyBzaG91bGQgYmUgYW4gZXhwbGljaXQNCj4gPj4gTVVTVCBOT1QN Cj4gPltSb25pIEV2ZW5dIFRoaXMgaXMgc3BlY2lmaWVkIGluIFJGQzUyODUgc2VjdGlvbiA2DQo+ ID4NCj4gPklkZW50aWZpZXJzIHZhbHVlcyBpbiB0aGUgdmFsaWQgcmFuZ2UgTVVTVCBOT1QgIGJl IGFsdGVyZWQgKHJlbWFwcGVkKS4NCj4gDQo+IENvcnJlY3QuIFRheWxvciBpbmRpY2F0ZWQgdGhp cyBlYXJsaWVyLg0KPiANCj4gV2hhdCBpZiBhIHByZXZpb3VzbHkgbmVnb3RpYXRlZCBtYXBwaW5n IGlzIG5vdCBpbmNsdWRlZCBhdCBhbGwgaW4gYSBzdWJzZXF1ZW50DQo+IG9mZmVyPw0KDQpbUm9u aSBFdmVuXSBJdCBpcyByZW1vdmVkIG5vdCBzdXBwb3J0ZWQgIkEgc2Vzc2lvbiB1cGRhdGUgTUFZ IGFkZCBvciAgcmVtb3ZlIGV4dGVuc2lvbihzKS4iDQoNCiBJcyBpdCBjb25zaWRlcmVkIGFuIGVy cm9yPw0KDQpbUm9uaSBFdmVuXSBubw0KDQogSWYgbm90LCBkb2VzIHRoZSBwcmV2aW91cyBtYXBw aW5nIGFwcGx5PyANCltSb25pIEV2ZW5dIGlmIHlvdSB3YW50IHRvIHVzZSBpdCB5b3UgY2FuIGNv bnNpZGVyIG1ha2luZyBpdCBpbmFjdGl2ZQ0KDQpPciwNCj4gaXMgdGhlIHByZXZpb3VzIG1hcHBp bmcgcmVtb3ZlZD8NCltSb25pIEV2ZW5dIHJlbW92ZWQgYnV0IHlvdSBjYW5ub3QgdXNlIHRoZSBz YW1lIElEIGZvciBhbm90aGVyIGV4dGVuc2lvbg0KDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gQ2hy aXN0ZXINCj4gDQo+IA0KPiANCj4gPiBGcm9tOiBJw7Fha2kgQmF6IENhc3RpbGxvIFttYWlsdG86 aWJjQGFsaWF4Lm5ldF0NCj4gPiBTZW50OiAwNyBBdWd1c3QgMjAxNyAxOTo1Ng0KPiA+IFRvOiBU YXlsb3IgQnJhbmRzdGV0dGVyIDxkZWFkYmVlZkBnb29nbGUuY29tPg0KPiA+IENjOiBDaHJpc3Rl ciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsNCj4gPiBydGN3ZWJA aWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW3J0Y3dlYl0gUmVwbGFjaW5nIGE9ZXh0bWFwIG1h cHBpbmcgaW4gcmUtb2ZmZXIsIGlzIGl0IGxlZ2FsPw0KPiA+DQo+ID4gT24gTW9uLCBBdWcgNywg MjAxNyBhdCA3OjQ2IFBNLCBUYXlsb3IgQnJhbmRzdGV0dGVyDQo+ID4gPGRlYWRiZWVmQGdvb2ds ZS5jb20+IHdyb3RlOg0KPiA+ID4gSSBkb24ndCBrbm93IGlmIHRoaXMgaXMgc3RhdGVkIGV4cGxp Y2l0bHkgYW55d2hlcmUsIGJ1dCBteQ0KPiA+ID4gYXNzdW1wdGlvbiB3YXMgdGhhdCBpdCB3b3Jr cyBsaWtlIHBheWxvYWQgdHlwZXMuIFlvdSBjYW4gaW50cm9kdWNlDQo+ID4gPiBuZXcgSURzIGFs bCB5b3Ugd2FudCwgYnV0IHlvdSBjYW4ndCBoYXZlIG9uZSBJRCByZWZlciB0byBtdWx0aXBsZQ0K PiA+ID4gdGhpbmdzIGR1cmluZyB0aGUNCj4gPiBzYW1lIHNlc3Npb24uDQo+ID4gPiBPdGhlcndp c2UsIGlmIHlvdSByZWNlaXZlIGEgcGFja2V0IHdpdGggdGhhdCBleHRlbnNpb24gSUQsIHlvdQ0K PiA+ID4gd291bGRuJ3QgYmUgYWJsZSB0byB0ZWxsIHdoaWNoIGV4dGVuc2lvbiBpdCBpcy4NCj4g PiA+DQo+ID4gPiBNZWFuaW5nLCBpZiBCb2IncyBpbml0aWFsIGFuc3dlciB3YXM6DQo+ID4gPg0K PiA+ID4gYT1leHRtYXA6MTEgaHR0cDovL3d3dy53ZWJydGMub3JnL2V4cGVyaW1lbnRzL3J0cC1o ZHJleHQvYWJzLQ0KPiBzZW5kLQ0KPiA+IHRpbWUNCj4gPiA+DQo+ID4gPiBJdCB3b3VsZCBiZSBp bGxlZ2FsIHRvIGhhdmUgYSByZS1vZmZlciBvZjoNCj4gPiA+DQo+ID4gPiBhPWV4dG1hcDoxIGh0 dHA6Ly93d3cud2VicnRjLm9yZy9leHBlcmltZW50cy9ydHAtaGRyZXh0L2Ficy1zZW5kLQ0KPiA+ IHRpbWUNCj4gPiA+IGE9ZXh0bWFwOjExIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnRvZmZz ZXQNCj4gPiA+DQo+ID4gPiBCZWNhdXNlIGlmIEJvYiB0aGVuIHJlY2VpdmVzIGEgcGFja2V0IHdp dGggZXh0ZW5zaW9uIElEIDExLCBCb2INCj4gPiA+IGRvZXNuJ3Qga25vdyBpZiBpdCdzIGEgcGFj a2V0IHNlbnQgYmVmb3JlIEFsaWNlIHJlY2VpdmVkIHRoZSBhbnN3ZXINCj4gPiA+IChpbiB3aGlj aCBjYXNlIGl0J3MgImFicy1zZW5kLXRpbWUiKSwgb3IgYWZ0ZXIgKGluIHdoaWNoIGNhc2UgaXQn cyAidG9mZnNldCIpLg0KPiA+DQo+ID4gVGhhbmtzLCB5b3VyIHJhdGlvbmFsZSBjbGVhcmx5IG1h a2VzIHNlbnNlLiBIb3dldmVyOg0KPiA+DQo+ID4gMSkgSSBkb24ndCB0aGluayBGaXJlZm94IGNh cmVzIGFib3V0IG92ZXJyaWRpbmcgYSBwcmV2aW91cyBleHRtYXAgSUQNCj4gPiBkdXJpbmcgYSBy ZW9mZmVyLg0KPiA+DQo+ID4gMikgU2hvdWxkIHdlIHJlYWxseSBhY2NlcHQgc28gY29tcGxleCBh bmQgZXJyb3IgcHJ1bmUgdGhpbmdzIGp1c3QNCj4gPiBiZWNhdXNlIFNEUCBhbGxvd3MgZXZlcnl0 aGluZz8NCj4gPg0KPiA+DQo+ID4gLS0NCj4gPiBJw7Fha2kgQmF6IENhc3RpbGxvDQo+ID4gPGli Y0BhbGlheC5uZXQ+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+ID4gcnRjd2ViQGlldGYub3JnDQo+ ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg== From nobody Thu Aug 10 14:42:57 2017 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FE3132379; Thu, 10 Aug 2017 14:42:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Cc: avtcore-chairs@ietf.org, ben@nostrum.com, The IESG , avt@ietf.org, roni.even@huawei.com, draft-ietf-avtcore-aria-srtp@ietf.org, Roni Even , rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150240136821.12035.7646222989249251664.idtracker@ietfa.amsl.com> Date: Thu, 10 Aug 2017 14:42:48 -0700 Archived-At: Subject: [AVTCORE] Document Action: 'The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP)' to Informational RFC (draft-ietf-avtcore-aria-srtp-11.txt) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 21:42:48 -0000 The IESG has approved the following document: - 'The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP)' (draft-ietf-avtcore-aria-srtp-11.txt) as Informational RFC This document is the product of the Audio/Video Transport Core Maintenance Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp/ Technical Summary This document defines the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP). It details two modes of operation (CTR, GCM) and a SRTP Key Derivation Function for ARIA. Additionally, this document defines DTLS-SRTP protection profiles and MIKEY parameter sets for the use with ARIA. ARIA is a Korean standard block cipher algorithm that has been widely used in Korea, especially for government-to-public services. Working Group Summary The primarily thing to note has been the limited interest in this work. However, since the draft registers DTLS-SRTP and MIKEY codepoints for a widely used algorithm, the AVTCORE group adopted the milestone. Document Quality The document has been reviewed by a small group of persons beyond the authors themselves. The document received feedback from Dan Wing and John Mattson from a security perspective. Colin Perkins, Jonathan Lennox, and the shepherd have reviewed it from an RTP perspective. There exist a number of implementations of the ARIA cipher in SRTP. Some are certified by Telecommunications Technology Association of Korea: http://test.tta.or.kr/research/result/index.jsp?team_cd=N&pageNum=2 And looking at specific products like: http://test.tta.or.kr/research/result/network.jsp?team_cd=N&num=987 http://test.tta.or.kr/research/result/network.jsp?team_cd=N&num=971 One can see (using Google translate) that they are listed as supporting ARIA. Shepherd notes that this likely means that the cipher and one form of key-management has been implemented. From nobody Fri Aug 11 08:33:15 2017 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE60D1320BD; Fri, 11 Aug 2017 08:33:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" Cc: jonathan@vidyo.com, rachel.huang@huawei.com, avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ietf@ietf.org Message-ID: <150246559393.24457.10070551344610544111.idtracker@ietfa.amsl.com> Date: Fri, 11 Aug 2017 08:33:13 -0700 Archived-At: Subject: [AVTCORE] WG Action: Conclusion of Audio/Video Transport Extensions (avtext) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 15:33:14 -0000 The Audio/Video Transport Extensions (AVTEXT) working group in the Applications and Real-Time Area has concluded. The IESG contact persons are Ben Campbell, Alexey Melnikov, and Adam Roach. The AVTEXT working group has been merged into AVTCORE, and is now closed as a separate working group. Current AVTEXT work and milestones have been moved to AVTCORE, and their discussion should continue on the AVTCORE mailing list ( avt@ietf.org ). Thanks for everyone's work in AVTEXT, and we hope to see you in AVTCORE. From nobody Mon Aug 28 05:30:01 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC41B132803 for ; Mon, 28 Aug 2017 05:29:58 -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 OqTxki1irSgF for ; Mon, 28 Aug 2017 05:29:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C15113217D for ; Mon, 28 Aug 2017 05:29:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DUH70348; Mon, 28 Aug 2017 12:29:54 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 28 Aug 2017 13:29:53 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.138]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0301.000; Mon, 28 Aug 2017 20:29:46 +0800 From: Roni Even To: "avt@ietf.org" Thread-Topic: New Version Notification for draft-even-avtcore-priority-markings-00.txt Thread-Index: AQHTHwsmxsmjrySRFUm1eAnEXc6kwKKZs6Eg Date: Mon, 28 Aug 2017 12:29:46 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD80013D@DGGEMM506-MBX.china.huawei.com> References: <150382108099.1001.10441908089429144954.idtracker@ietfa.amsl.com> In-Reply-To: <150382108099.1001.10441908089429144954.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.75] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.59A40CC2.0096, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.138, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 887360ad65b32eb0d7ff7907462c292c Archived-At: Subject: [AVTCORE] FW: New Version Notification for draft-even-avtcore-priority-markings-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 12:29:59 -0000 SGksDQpJIHN1Ym1pdHRlZCBhIGRyYWZ0IHByb3Bvc2luZyB0byBhZGQgcHJpb3JpdHkgdmFsdWVz IGZvciB0aGUgbm9uLXNjYWxhYmxlIHN0cmVhbXMgZHJvcHBhYmxlICBmcmFtZXMgaW4gdGhlIGZy YW1lIG1hcmtpbmcgUlRQIGhlYWRlciBleHRlbnNpb24uDQpUaGlzIGRvY3VtZW50IHdhcyBzdWJt aXR0ZWQgYXMgcHJvcG9zZWQgaW4gdGhlIEFWVGNvcmUgUHJhZ3VlIHNlc3Npb24uDQpJdCBhbHNv IGV4cGxhaW4gdGhlIHVzYWdlIGZvciB0aGVzZSBiaXRzLg0KVGhhbmtzDQpSb25pIEV2ZW4NCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiDXmdeV153CoNeQIDI3 INeQ15XXkteV16HXmCAyMDE3IDExOjA1DQpUbzogT2ZlciBJZGFuIChUUkMsIE5ldHdvcmsgcmVz ZWFyY2gpOyBSb25pIEV2ZW4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtZXZlbi1hdnRjb3JlLXByaW9yaXR5LW1hcmtpbmdzLTAwLnR4dA0KDQoNCkEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC1ldmVuLWF2dGNvcmUtcHJpb3JpdHktbWFya2luZ3MtMDAudHh0 DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJvbmkgRXZlbiBhbmQgcG9zdGVk IHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1ldmVuLWF2dGNvcmUtcHJp b3JpdHktbWFya2luZ3MNClJldmlzaW9uOgkwMA0KVGl0bGU6CQlGcmFtZSBQcmlvcml0eSBNYXJr aW5nIFJUUCBIZWFkZXIgRXh0ZW5zaW9uDQpEb2N1bWVudCBkYXRlOgkyMDE3LTA4LTI3DQpHcm91 cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk0DQpVUkw6ICAgICAgICAgICAgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWV2ZW4tYXZ0Y29yZS1wcmlv cml0eS1tYXJraW5ncy0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1ldmVuLWF2dGNvcmUtcHJpb3JpdHktbWFya2luZ3MvDQpIdG1s aXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWV2ZW4tYXZ0Y29y ZS1wcmlvcml0eS1tYXJraW5ncy0wMA0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtZXZlbi1hdnRjb3JlLXByaW9yaXR5LW1hcmtpbmdz LTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgdGhlIEZyYW1lIE1h cmtpbmcgUlRQIGhlYWRlciBleHRlbnNpb24gaW4NCiAgIGRyYWZ0LWlldGYtYXZ0ZXh0LWZyYW1l bWFya2luZy0xNCB1c2VkIHRvIGNvbnZleSBpbmZvcm1hdGlvbiBhYm91dA0KICAgdmlkZW8gZnJh bWVzIHRoYXQgaXMgY3JpdGljYWwgZm9yIGVycm9yIHJlY292ZXJ5IGFuZCBwYWNrZXQNCiAgIGZv cndhcmRpbmcgaW4gUlRQIG1pZGRsZS1ib3hlcyBvciBuZXR3b3JrIG5vZGVzLiAgVGhlIGZsYWdz IGZvciBmcmFtZQ0KICAgbWFya2luZyBmb3Igbm9uLXNjYWxhYmxlIHN0cmVhbXMgaW5jbHVkZSB0 aGUgRCBiaXQgdG8gbWFyayBhIGZyYW1lDQogICB0aGF0IGNhbiBiZSBkaXNjYXJkZWQsIGFuZCBz dGlsbCBwcm92aWRlIGEgZGVjb2RhYmxlIG1lZGlhIHN0cmVhbS4NCiAgIFRoZXJlIGlzIGFsc28g dGhlIEkgYml0IGZvciBmcmFtZXMgdGhhdCBjYW4gYmUgZGVjb2RlZCBpbmRlcGVuZGVudCBvZg0K ICAgcHJpb3IgZnJhbWVzLCBlLmcuIGludHJhLWZyYW1lLg0KDQogICBUaGlzIG1lbW8gYWRkcyBw cmlvcml0eSB2YWx1ZXMgZm9yIHRoZSBub24tc2NhbGFibGUgc3RyZWFtcyBkcm9wcGFibGUNCiAg IGZyYW1lcw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo=