Re: [MMUSIC] [dispatch] draft-davis-valverde-srtp-assurance [was: Re: IETF 117 - do you have something for DISPATCH?]
"Kyzer Davis (kydavis)" <kydavis@cisco.com> Tue, 15 August 2023 16:46 UTC
Return-Path: <kydavis@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65C4C151555; Tue, 15 Aug 2023 09:46:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.594
X-Spam-Level:
X-Spam-Status: No, score=-9.594 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b="XsWPLW0w"; dkim=pass (1024-bit key) header.d=cisco.com header.b="aXXITgAR"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S57ntiCOPBhp; Tue, 15 Aug 2023 09:46:50 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925B1C14CE3F; Tue, 15 Aug 2023 09:46:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46598; q=dns/txt; s=iport; t=1692118010; x=1693327610; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+JTgw2gYTi/8lKBl9oA5HohOTFyiYGAvSghm+cMCMMU=; b=XsWPLW0wZsDTMZLGvKEIemvpsc+n6E9bLYyrk1q+S27vY3jD29bGLnL1 maDZ7XcGrOK4XAyy5IwoL6RzXnt3gnuUaTQj3C51MnZ6eDwhhQvyll7XS e6JFa/pZzdtb6x2wFDRetZkni87K/rFbtbEHVM55Xx7+trUPiAkkMYKXY w=;
X-Files: smime.p7s : 5465
X-IPAS-Result: A0ACAACFq9tkmJBdJa1aGQEBAQEBAQEBAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFlgRYEAQEBAQELAYEvMVJ0AisuKhJHA4ROg0wDhE5fiGADi1qMCIE4hF+BJQNRBQgHAQEBCgMBAS4BDgcEAQGEQEYChl0CJTQJDgECAgIBAQEBAwIDAQEBAQEBAwEBBQEBAQIBBwQUAQEBAQEBAQEeGQUOECeFaA2GBAEBAQECAQEBEAgJChMBASUHCwEECwIBCBEEAQEBIAECBAMCAgIfBgsUCQgCBAENBQgGDAEHglwBghYUAw4SEQMBEAaeVgGBQAKKJnqBMoEBggkBAQYEBYFOQa4HDYJCBwMGgUIBgVaGDAQaAQVgZQEBgVmBAoEGGAmDDYEfJxuBSUSBFUOBZoECPoEFgRtCAQECAYFfFRYJgyU5gi6Efj6DQ26FSwcygUxgg2eHNCqBCAhfgW89Ag1VCwtjgRWCRwICEToTSnEbAwcDgQQQLwcEMgcWBwYJFy8lBlEHLSQJExVABIF4gVYKgQY/FQ4Rgk4iAgc2OBlLgmYJFUA7FXgQLgQUGIEUBEslBRoVHjgREhkNAwh7HQI0PAMFAwQ2ChUNCyEFFEMDSAZQCwMCGgNEHUADC2gFDgItNRQbBQRmWQWcV4EQChQ9NBOBQhAVTBEdECpRAhRGAQsVSj4BAScGBQMDKw+SPAETg1CtJG8KhAuGS4MpZ4EjjxSGKBeEAZNZkR9ih2GQSSCCL4sRg3SRKRMNhHwCBAIEBQIOAQEGgWM6gVtwFTuCMwEBMlIZD44gDA0JFYM9hRSKZAF2AgsuAgcBCgEBAwmGSIUAAQE
IronPort-PHdr: A9a23:4EeVRh/bTR261v9uWO7oyV9kXcBvk6//MghQ7YIolPcUNK+i5J/le kfY4KYlgFzIWNDD4ulfw6rNsq/mUHAd+5vJrn0YcZJNWhNEwcUblgAtGoiEXGXwLeXhaGoxG 8ERHER98SSDOFNOUN37e0WUp3Sz6TAIHRCqNht5L/r0AabZjt+80Ka5/JiAKwlNjSC2NKt7N w7+7R2Er9Qfm4JkNqc3x1PFo2AdfeNQyCIgKQeYng334YG7+5sLzg==
IronPort-Data: A9a23:k564bqPn3baEQWbvrR0hl8FynXyQoLVcMsEvi/8bNHDolHp+jmZWi jtAB3bGYazJZX+2Io4oOcnztx82DaSljYs6FVdy7S52J54hgcbJWNiTfxf8Y3yfcZWbFR46v 5sXZ9DMdMxkRSOE9h2nbee/8nAk2K2GH+f2U7KfZ3ooHAM6FHx61Uo9krdpi4UAbbRVbe+ok YuaT5r3ZQP7hlaYS14p1p9viC+Dndyq6GwR5g1kO/xA4QHUxyRIU5wTfPu7cSHxHINYQ+DqH M/Oneqzlo/7E7jBKT8EfpLTKBBirmv6ZFDW4pZuc/H+xEAE/ETe645jXBYmQR8/Zw6hwZYpk b2hibTqEV1yZv2VxbxHO/VlO3gW0ZNuqeevzUeX6aR//2WeG5c766wzZK2eFdRwFtdfWQmix 9RBQNw+Rkzra9aN/V6OYrIEavLPgyXcFNh3VnlIlVk1BBu9KHzJa/2iCdRwhF/cii3SdBrTT 5JxVNZhUPjPSwBvawwdMa5jp6Dyl3TzeDFZo0urgoNitgA/zCQpuFTsGMDedtrPTsJPkwPI4 GnH5G/+RBodMbRzyxLcrSnq3bCJzHi9Ad5OfFG73qYCbFm7xX0fAQMXTnOwoOKyjQi1XNc3x 0k8o3J3/fdjqBLwJjX7d0WCmm6DgjIyYfVZE+gCxy61zvrT7S/MUwDoSRYYOIB566faXwcC0 1qUhNLiLT1irLPTTmiSnp+YrCiqMDQeLUcDaDMKCwwf7LHeTJoblBnDSJNoF7S4y42zEjDry DfMpy8771kOsSIV/7ibrAvNug7xnd+TXwM57QnWVXubySosMeZJeLeUwVTc6P9BKqOQQV+Ao GUIlqCiAAYmUM/leMulHbtlIV252xqWGGaD3gM3TvHN4xzoqiHzJ9kBiN1rDB4xap5sRNP/X KPEVepsCHJ7JnCma+p8ZJi8TpRsxqn7HtOjXffRBjavXnSTXFHelM2NTRfAt4wIrKTKufpvU Xt8WZr1ZUv28Yw9kFKLqx41iNfHPBwWy2LJXozcxB+6y7eYb3P9Ye5bYQHWNb9pt/nU/Vq9H zNj2y2ilU03vArWPHG/zGLvBQtiwYUTXMqv8JUHKoZv3CI3Rj1J5wDtLUMJItw5wPs9ehbg9 XCmUUgQ00vkmXDCMm23hoNLNtvSsWJEhStjZ0QEZA/ws1B6ONrHxPlELfMfI+J4nNGPONYpF ZHpje3aXKQWItkGkhxABaTAQHtKLU302l3QYXv+MVDSvfdIHmT0xzMtRSO2nAEmBSusvsx4q Lqlvj43i7JaL+i+JK46sM6S8m4=
IronPort-HdrOrdr: A9a23:olgrOaPluwPrJsBcT2P155DYdb4zR+YMi2TDiHoRdfUFSKKlfp 6V88jzjSWE9wr5OEtLpTiBUJPwJk80hqQFn7X5XI3SEDUO3VHJEGgM1/qY/9SNIVyaygcZ79 YdT0EcMqy+MbEZt7eB3ODQKb9Jq7X3k9HLuQ6d9QYRcegAUdAH0+4NMHfiLqQAfng+OXNWLu v52iNAnVedUEVSSv7+KmgOXuDFqdGOvonhewQ6Cxku7xTLpS+06ZbheiLonys2Yndq+/MP4G LFmwv26uGIqPeg0CLR0GfV8tB/hMbh8N1eH8aB4/JlagkEyzzYJ7iJaYfy+Qzdk9vfrGrCV+ O85CvICv4DqU85uFvF5ycFlTOQiQrGoEWSuWNwyUGT0vDRdXYfB81dhYRfaHLimjsdVZdHoe x2N6bzjesNMfsG9x6Nv+TgRlVkkFG5rmEllvNWh3tDUZEGYLsUtoAH+lhJea1wVx4SxbpXWd WGNvusrMp+YBefdTTUr2NvyNujUjA6GQqHWFELvoiQ3yJNlH50wkMEzIhH901wua4VWt1B/a DJI65onLZBQosfar98Hv4IRY+yBnbWSRzBPWqOKRDsFb0BOXjKt5nriY9Frt2CadgN1t8/iZ 7BWFRXuSo7fF/vE9SH2NlR/hXEUAyGLELQIwFllu9EU5HHNc7W2He4OSITeuOb0oAiPvE=
X-Talos-CUID: 9a23:LOhw/GsM5h5iHuvAQmPXSk026Is4UiyGxk7sfnT/U3dkRLaZSFSJxoRNxp8=
X-Talos-MUID: 9a23:kaVTYgl8OhD2kC1YMxiTdno6Dv145JiCJnoimJUDg+arDSggPDm02WE=
X-IronPort-Anti-Spam-Filtered: true
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Aug 2023 16:46:49 +0000
Received: from rcdn-opgw-2.cisco.com (rcdn-opgw-2.cisco.com [72.163.7.163]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 37FGkmNE004757 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 15 Aug 2023 16:46:49 GMT
Authentication-Results: rcdn-opgw-2.cisco.com; dkim=pass (signature verified) header.i=@cisco.com; spf=Pass smtp.mailfrom=kydavis@cisco.com; dmarc=pass (p=quarantine dis=none) d=cisco.com
X-IronPort-AV: E=Sophos;i="6.01,175,1684800000"; d="p7s'?scan'208,217";a="320076"
Received: from mail-dm3nam02lp2040.outbound.protection.outlook.com (HELO NAM02-DM3-obe.outbound.protection.outlook.com) ([104.47.56.40]) by rcdn-opgw-2.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Aug 2023 16:46:48 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ncJFvRLwxb6eFNVUx1N5ZhFi+gF7nOj0sbETxy5E64yLk3/+6xlncKIOc7samM0VEsITVv6uwGvNDLW9LUqrdaa4a8Zgh39sctB47DYqDdqCUGgiUIryQZtQ/8cRCB3a+EL/O96EH0FTjlDvYg5kyItXMuG12jM9cypFrkFxYb3jZWt2ubpFusdfNgtDqYujMiBbgc5A3RPwEOrk2ch+xDgSFhWu8O4FtpTXzzcEWzTqYKvKUIzVCufV3djWKBZqoreYUYFFjDra0tzeGrL7L0CVVDm14fpRe734D+ny3gEaYfnhk1XwSx+CNmBNDsFeCW9Wc2jWOn2qbLnpJqvK0A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4DM2qq30NJN40cj0H76dql8fs8LyMGoeFfSnxIFTAis=; b=WZplWlzMhkG+/f+dwRch5vUukn65xXdR601kPnkXQnf+Fo4Cf/B8GVLqdZ+KWiaZoF4OOkvQ6kv2kShRLNlPAXx5cbRGNRpW3XzbF2jmnYmHNAeOp7WLGqWi72d/0tuXuyTkict/o8ks30n3GQXr984JnN8r5lVLpe1RcoejC5rkniBHNUWdbpImeRIBmecvt3kDnUS5L8qBIjU6x7nSwXBmgox4jRlESZqENIonEDsrDJAYK6ZFhosxnwgxqpkUMyDCcHzdMw/5YO3Qvi4oW48847D1jdAS23OcVQ1gKXMlx5qujFIJhZxrlNPJo8b6jhLsAHhO+U942bp2pCIeWw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4DM2qq30NJN40cj0H76dql8fs8LyMGoeFfSnxIFTAis=; b=aXXITgARs6LglU9xPl81O91f0ZpYr5Z25gl6mJtl3L9mMspajSk//zL9AQz0A8/CzsJDcTtQ0QeFbHdfOOhRkMPh515DhGKAXovAH3gi+hOPrgUnrUb7rTqWDyIgjqwGYDKeXww0SCeu3NTa7+YNNWefHQiMpjyhjrXX0Lu9ni0=
Received: from PH0PR11MB5029.namprd11.prod.outlook.com (2603:10b6:510:30::15) by DS0PR11MB7481.namprd11.prod.outlook.com (2603:10b6:8:14b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6678.24; Tue, 15 Aug 2023 16:46:46 +0000
Received: from PH0PR11MB5029.namprd11.prod.outlook.com ([fe80::c41f:e33b:88b:88d9]) by PH0PR11MB5029.namprd11.prod.outlook.com ([fe80::c41f:e33b:88b:88d9%6]) with mapi id 15.20.6678.025; Tue, 15 Aug 2023 16:46:45 +0000
From: "Kyzer Davis (kydavis)" <kydavis@cisco.com>
To: Roman Shpount <roman@telurix.com>, "DuBois, Sean" <sean@siobud.com>, "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>
CC: Brian Rosen <br@brianrosen.net>, "dispatch@ietf.org" <dispatch@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] [dispatch] draft-davis-valverde-srtp-assurance [was: Re: IETF 117 - do you have something for DISPATCH?]
Thread-Index: AQHZz4l+iGSksTGb00mfwHDazBY69a/reE2AgAAHVYCAAAMiAIAACacQ
Date: Tue, 15 Aug 2023 16:46:45 +0000
Message-ID: <PH0PR11MB5029A923C0C97094992793C0BB14A@PH0PR11MB5029.namprd11.prod.outlook.com>
References: <0490249B-C51B-4E18-8155-144CE044E994@gmail.com> <PH0PR11MB50293AD3FEDA894B9B2D3041BB3BA@PH0PR11MB5029.namprd11.prod.outlook.com> <2DEC9659-A76A-4D33-ADDE-CDB7D5E5EBED@brianrosen.net> <CAD5OKxuoowrzZ79gUm8t7mOgPybF__VUaF4we_MN=XWmZS9uHg@mail.gmail.com> <EF959CF6-BC21-468E-A65C-94FD4DF8DB84@siobud.com> <CAD5OKxuEn3V7JO8xXxt5pzFZnVzkxWWZEFVD-pVZGzfyWWw=Pg@mail.gmail.com>
In-Reply-To: <CAD5OKxuEn3V7JO8xXxt5pzFZnVzkxWWZEFVD-pVZGzfyWWw=Pg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-Mentions: gsalguei@cisco.com
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH0PR11MB5029:EE_|DS0PR11MB7481:EE_
x-ms-office365-filtering-correlation-id: f9e1f306-d8fa-4ae4-3117-08db9daf3631
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: pU24p9UbnIeou4EQ3G+RP/SmvT6DamJCCmlDO5MJ73p/6YqNRSaGT3NP9tSLezXtuLNidXihDh6+SbzRk44Sk4UU1HSVAjmVVFxHZiGNNV7C8k63mz03AL7FVGOUUtG7hgKd95jx+vVjtme3ow6XIbU2hWIxSJEl3Fe8xEl8/9bw1XEsHOVRBY+PWP0ABoWRbSaQTBIMsYHUmTUFJU7Y2/oN5+CsOLV7t1UhMAWUci3JaPAkC79bAJEToxXsX//QIrhuyXMU83W7wACKsEJPnewdtYgDz0NTdgJFlpfWjSfzVbcgMa2Pl8JZhxJWq3t671uelAb6ZnaR1GDiRcof5KZjIQ0e7gg3rHChcvC+p1snddsc5FqnNkywo5fF0vC429yEliG/pv83CDNBtm2xn/IV90Hm2i+a4AbtOWghILCVwLNWxK8GHtNQ66MTPymjY9/IguvLf9QXVA1Y04WwjosnEIEkFbSI7+vQMsrYdCU2CLpZgmYuz7jc0Xnjt+s9crM+rijMv4gMbcKg6cd/slQ+CUP9FTzoTG9JX15ByHTfvgZJUAgBfgiam1qVdXsF9nSwd/oke//l/vGEDLNmvfJrYyBsMGiN3q1DrEBmzI8drn+IZqmctWVqISZbXzA91kxYVKJm4+P80Bnq48HcoA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5029.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(376002)(366004)(396003)(136003)(346002)(39860400002)(451199024)(1800799009)(186009)(54906003)(55016003)(66899024)(38070700005)(52536014)(6636002)(4326008)(122000001)(2906002)(5660300002)(166002)(966005)(66556008)(8936002)(64756008)(41300700001)(26005)(76116006)(6506007)(66946007)(86362001)(478600001)(30864003)(33656002)(66476007)(66446008)(316002)(8676002)(9686003)(83380400001)(53546011)(7696005)(99936003)(71200400001)(66574015)(110136005)(38100700002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: J/kJlQSCQcbAWKYhDI00Q/k+g/uH79hZ8enBWObG1dr0PwmidZbjaCGxkSFO8Bz05lH99NivvuTUVG2uILaP+X/0AqA8jD0Zb2NyC0CtjLoFERyzIpdy0vsKw4iJHpv07OHnAjX6dBfzlZb5P0kKBFTZ8IN3F66azIDdfQUbO9TPRfmTfJZulIWDjGaTXr2aJ71KtgKUk4tKmUwiE6UyM4eCL/sQ1jAfSKz3JDo6maymBQB9n1JJ4AMlPLP6JoOZQ84ALJShwyCMmKJu5+hbX7t++NVx/zo2QqxYMH4kQYDxC7OoT3g9K7JphD18JE3OvgR5mynB00t2fLiYtK+LSHQulxJrxT74mDjryaiOVgJ7p5Tto7+dewLahGBicykaShjMY2HB2aFg+GuPaI1cQkPktE2+naKTm9YbJZkA9znnpHh7HcPSJ458UZjX+PSdejqE7sy/O/KHvWXBQUhBNT7X1+z+R20FzixhYCUMQzuLSIwSDZVx2pFof2/n2WLaU7IyBT5/DjC22v1sJ6l1ozJ/Vhja97oEjffKcMzqgrwOrOAVvw64bR+yJrD7/MfYPw7iTyqF8H3TwR8SfUvDxZolyD+wPG3r0XWDCZbMSOJCcmrcLyvHUuBWRkuDZZGBk6SADbaeDmZA3EtffxUNDrFC/sgxMtd7ihXllvZdeS/zw4W2vSU1Xle6LZTjkPB7Jxq01T+ytR4w8ELBKVxauxZwBCW6/dzxoh1iSVog5PtZt5y88L/q/NC81U324g4M1LcyP6K/AwrY6QC4V4qDqLNQbJxoFczNgPUnmAeWEMrYs6d9zkCcYloYv0JMcS08HEdOChdyMQAVP309uF6CDju3SmPF4ijdQXaW0vDFbQMOFH4mjgDddvSJ4yL29JklpjPkfjqPvOP9KdGfcYfvx0rWCkcNYUz34LE7p1d2RUzgp71fI47iCBDrNBM9CH/xRBZC7Nkip06YCgafm4ckm3EMmHacKbBDzLmWk1G9TFTVHv4unOYLe02Z9ZSc78K5PUBFlsMdEQPbdOI58uqYSBHM7ux/F5fpkzAONDZzSt2yu+lUR4QQa0zTWF7EhZuX0qlbKup3uTZhqJZqpGO7cEa+LCvS46Q5qeq42zPf+IfXA4WlDcgXWlejDWI1KQ9P55YlzNBI6BZCo/ZXGWjV7rq2WslmwssBnRnEonmA0DpE3JIIjftwp+XyCglJLd3tl/EBq4LaoU4wUDmUnXhZ9xdOU7PFRoRgZwGS3yEU/u8a6Ot93i4tQt1M7d70H3P+OoFUrTxupilCX6DpxGdZJfxsfGNw+dJjey/gCMurk+2cN/7O0XX1kth3BcB7rbfvL0sxiIBk+ltc66v3q2FMu07w8rGYqqXBO7D3KEw7n9cy7TfUoz/xgYTCHl3t7cJsVhdhrujEWt2ZIydq8I6w1NIjb9YWHRq+7s1yivUb7YS/8KkbGg/kq0Zz8NIjhQVZhu35JYNJK+AZ932xyQoLRjZaCikXBnBqj8EFZGMa1htB9X8HcqjxwkycND4lkhrPB+QW2UTrmMwXtnuv64gPk2HG3ns6hCSc1x1jK/F1Y2Q=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_004A_01D9CF76.8AC0C500"
MIME-Version: 1.0
X-OriginatorOrg: cisco.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5029.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f9e1f306-d8fa-4ae4-3117-08db9daf3631
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2023 16:46:45.6851 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Ss5sGRaGfKJWpNLNEnssuYlcG+oy5HwP17AgFIg4XYNOVHivqyhNhcdxSsoTH0mOHoTs3m1OLqObFHIXyInHXg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB7481
X-Outbound-SMTP-Client: 72.163.7.163, rcdn-opgw-2.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/mn5Vh7NMAbIzNWwA43HUFsU8Ry0>
Subject: Re: [MMUSIC] [dispatch] draft-davis-valverde-srtp-assurance [was: Re: IETF 117 - do you have something for DISPATCH?]
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Aug 2023 16:46:54 -0000
> Many people promote DTLS-SRTP, but DTLS-SRTP is not a fully featured replacement for SDES-SRTP. > DTLS-SRTP negotiation was patched up to work with WebRTC, but it will not work for all the scenarios where SDES-SRTP is used. This is one of my biggest points for keeping SDES up-to-date and solving faults in the underlying protocol with a huge deployment base. > Now that DTLS has Connection Identifiers (RFC9146) I have been running multiple DTLS sessions on the same 5-Tuple. > This means, however, that RFC5763 and RFC8842 would need to be updated, which is definitely something that MMUSIC should consider. I agree with the statement that MMUSIC should take up multiplexing DTLS-SRTP sessions over the same 5-tuple. It may be interesting to add in some updates about DTLS-SRTP w/DTLS 1.3 since there was some discussion[1] on the TLS mailer around how freezing DTLS 1.2 would affect DTLS-SRTP. I was speaking with <mailto:gsalguei@cisco.com> @Gonzalo Salgueiro (gsalguei) and we would be happy to take up any DTLS-SRTP update work as well. That being said, I view these two SRTP key management related efforts as two parallel activities that need not step on each other. Thanks, Kyzer Davis [1] <https://mailarchive.ietf.org/arch/msg/tls/HPjmj71UeTgK3LhqagfjG9C2tNo/> https://mailarchive.ietf.org/arch/msg/tls/HPjmj71UeTgK3LhqagfjG9C2tNo/ From: Roman Shpount <roman@telurix.com> Sent: Tuesday, August 15, 2023 11:56 AM To: DuBois, Sean <sean@siobud.com> Cc: Brian Rosen <br@brianrosen.net>; Kyzer Davis (kydavis) <kydavis@cisco.com>; dispatch@ietf.org; mmusic@ietf.org Subject: Re: [MMUSIC] [dispatch] draft-davis-valverde-srtp-assurance [was: Re: IETF 117 - do you have something for DISPATCH?] Hi Sean, This is great news. This means, however, that RFC5763 and RFC8842 would need to be updated, which is definitely something that MMUSIC should consider. DTLS does not need to be SSRC aware, but there should be a way to signal the DTLS connection Identifier in SDP so that the fingerprint attribute is associated with the correct DTLS session. Potentially we can reuse tls-id for this purpose. This can be addressed in the RFC8842 update. Best Regards, _____________ Roman Shpount On Tue, Aug 15, 2023 at 11:44 AM DuBois, Sean <sean@siobud.com <mailto:sean@siobud.com> > wrote: Now that DTLS has Connection Identifiers (RFC9146) I have been running multiple DTLS sessions on the same 5-Tuple. Does DTLS need to be SSRC aware. SSRC can stay in the Session Description I believe? Thanks On Aug 15, 2023, at 11:18 AM, Roman Shpount <roman@telurix.com <mailto:roman@telurix.com> > wrote: Hi Brian, Many people promote DTLS-SRTP, but DTLS-SRTP is not a fully featured replacement for SDES-SRTP. The problem with DTLS-SRTP is it cannot reuse the same pair of 5-tuples for two different sessions. To deprecate SDES-SRTP, DTLS-SRTP should be enhanced to handle two DTLS handshakes over the same transport address and a mechanism to associate these handshakes with SSRC. DTLS-SRTP negotiation was patched up to work with WebRTC, but it will not work for all the scenarios where SDES-SRTP is used. Without the standard update, the most likely result of the DTLS-SRTP regulatory requirements for Next Gen 9-1-1 would be that emergency calls will be dropped. Also, considering the external dependency on TLS, I don't think MMUSIC can add the required functionality on its own. Best Regards, _____________ Roman Shpount On Tue, Aug 15, 2023 at 11:02 AM Brian Rosen <br=40brianrosen.net@dmarc.ietf.org <mailto:40brianrosen.net@dmarc.ietf.org> > wrote: A piece of info that might affect the discussion of prolonging SDES vs DTLS-SRTP. In the US, the regulator announced an intention to require all carriers, including VoIP carriers to support “Next Generation 9-1-1” signaling. That requires SIP with DTLS-SRTP. The emergency call service side does not support SDES. Of course, security is hop by hop, and nearly every carrier anchors media, so the DTLS-SRTP connection is likely from the carrier’s SBC to the emergency services SBC, and the phone could still support SDES, but it’s another nail in the SDES coffin. I would be opposed to enhancing SDES. Implementing this draft would require code changes in the device that needed it. I would prefer those changes implement DTLS-SRTP. While I do recognize that the magnitude of a change to implement DTLS-SRTP, with EKT-SRTP would be much greater than implementing this draft on a device that implemented SDES, a change is a change, and I think the security of DTLS-SRTP is so much better than SDES, that I believe we should not encourage continuing deployment of SDES. Brian On Jul 17, 2023, at 5:09 PM, Kyzer Davis (kydavis) <kydavis=40cisco.com@dmarc.ietf.org <mailto:40cisco.com@dmarc.ietf.org> > wrote: Hello Dan, I reached out to the MMUSIC chairs (along with AVTCORE Chairs and Dispatch chairs CC’d) MMUSIC felt like it belonged but still wanted the dispatch time since there is no MMUSIC meeting at 117. To address a few other statements: > I would like to understand where EKT-SRTP (RFC8870) fails to meet needs. I think EKT-SRTP does a great job. That is, if we are using DTLS-SRTP. I am only aiming to do the same for SDP Security (SDES). > I would rather see RFC8870 extended to work with SDP Security Descriptions because it moves us on a path towards DTLS-SRTP: DTLS-SRTP-signaled endpoints could interop with SDP Security Descriptions-signaled endpoints because they're both using EKT to handle SSRC/ROC and key changes when group membership changes. I believe you are referencing the act of an SBC/B2BUA interoperating SDP Security and DTLS-SRTP w/EKT? I found some older EKT-SRTP drafts that I think are the topic: https://www.ietf.org/archive/id/draft-mcgrew-srtp-ekt-06.html#anchor6 https://www.ietf.org/archive/id/draft-mcgrew-srtp-ekt-06.html#anchor21 One point discussed in there was “SDP Security Descriptions however does not negotiate SSRCs and their associated Rollover Counter (ROC). Instead, SDES relies on a so-called "late binding", where a newly observed SSRC will have its crypto context initialized to a ROC value of zero. Clearly, this does not work for participants joining an SRTP session that has been established for a while and hence has a non-zero ROC.” If that is the point then I agree; having the SSRC, ROC, SEQ in SDES/SDP security could allow for an intermediary to easily interwork SDES<>DTLS-EKT-SRTP. Note: I would need to audit EKT-SRTP to see if there is anything else SDES is missing that could help that Key Management Interworking. > We really should be deprecating SDP Security Descriptions because it has far worse security properties compared with DTLS-SRTP. I also know SDP as a means for conveying keying material for SRTP isn't exactly the best method in the grand scheme when compared to the other available options. That being said, there are many millions of devices across different vendors still using SDP Security as the SRTP key management protocol. Further, I continue to see more modern internet telephony service providers providing TLS SIP w/SRTP via SDES and the acceleration of cloud registered SIP endpoints utilizing SDP Security. Ignoring the problem that could positively affect so many does not seem like the right thing to do. Other: I started an audit of various enterprise, cloud and service provider offerings to compare MIKEY, DTLS-SRTP, EKT-SRTP, and SDP Security but I will not be able to finish this by the time for dispatch so I have dropped the slide. I can create a wiki page on the drafts GitHub if the group wants to help crowdsource a “Current State of SRTP Key Management Protocol offerings in 2023”. Similarly, if a similar study already exists I would love to give it a read. Lastly, I have a WIP draft-01 which provides an alternative solution to draft-00’s a=srtpctx SDP attribute. The alternative solution reuses the sdp security session parameter postfix options to convey SSRC, ROC, SEQ. https://www.iana.org/assignments/sdp-security-descriptions/sdp-security-descriptions.xhtml#sdp-security-descriptions-4 I plan to have a slide on both solutions for the dispatch discussion. Thanks, From: Dan Wing <danwing@gmail.com <mailto:danwing@gmail.com> > Sent: Monday, July 17, 2023 3:41 PM To: dispatch@ietf.org <mailto:dispatch@ietf.org> Cc: Kyzer Davis (kydavis) <kydavis@cisco.com <mailto:kydavis@cisco.com> >; Robert Sparks <rjsparks@nostrum.com <mailto:rjsparks@nostrum.com> >; mmusic@ietf.org <mailto:mmusic@ietf.org> Subject: draft-davis-valverde-srtp-assurance [was: Re: [dispatch] IETF 117 - do you have something for DISPATCH?] Yeah, it feels like draft-davis-valverde-srtp-assurance could go straight to MMUSIC. The I-D needs to discuss what happens when SSRC collision occurs, which I think is "send new SDP indicating the new SSRC and ROC=0". I would like to understand where EKT-SRTP (RFC8870) fails to meet needs. The design of EKT-SRTP avoids signaling SSRC or ROC in the signaling channel and, instead, allow them both to be indicated in the SRTP channel itself. This design allows SSRC collisions to be handled very much like how they are handled with RTP (that is, without the "S"). I would rather see RFC8870 extended to work with SDP Security Descriptions because it moves us on a path towards DTLS-SRTP: DTLS-SRTP-signaled endpoints could interop with SDP Security Descriptions-signaled endpoints because they're both using EKT to handle SSRC/ROC and key changes when group membership changes. We really should be deprecating SDP Security Descriptions because it has far worse security properties compared with DTLS-SRTP. -d Hi Kyzer (et. al.) - Why aren't you taking this straight to mmusic? Am I missing something that says that's not the obvious place for the work? RjS On 6/27/23 7:31 AM, Kyzer Davis (kydavis) wrote: > > Hello, > > I would like to request a bit of dispatch time for the draft just posted: > > <https://datatracker.ietf.org/doc/draft-davis-valverde-srtp-assurance/> https://datatracker.ietf.org/doc/draft-davis-valverde-srtp-assurance/ > > I also plan to attend IETF 117 in person to represent. > > Thanks, > _______________________________________________ dispatch mailing list <mailto:dispatch@ietf.org> dispatch@ietf.org <https://www.ietf.org/mailman/listinfo/dispatch> https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ mmusic mailing list mmusic@ietf.org <mailto:mmusic@ietf.org> https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org <mailto:mmusic@ietf.org> https://www.ietf.org/mailman/listinfo/mmusic
- [MMUSIC] draft-davis-valverde-srtp-assurance [was… Dan Wing
- Re: [MMUSIC] draft-davis-valverde-srtp-assurance … Kyzer Davis (kydavis)
- Re: [MMUSIC] draft-davis-valverde-srtp-assurance … Dan Wing
- Re: [MMUSIC] [dispatch] draft-davis-valverde-srtp… Brian Rosen
- Re: [MMUSIC] [dispatch] draft-davis-valverde-srtp… Roman Shpount
- Re: [MMUSIC] [dispatch] draft-davis-valverde-srtp… DuBois, Sean
- Re: [MMUSIC] [dispatch] draft-davis-valverde-srtp… Roman Shpount
- Re: [MMUSIC] [dispatch] draft-davis-valverde-srtp… Kyzer Davis (kydavis)
- [MMUSIC] DTLS-SRTP updates Roman Shpount