From nobody Tue Apr 2 04:03:29 2019 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1631200E0; Tue, 2 Apr 2019 04:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=ericsson.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 VQ86hJGIJ5ax; Tue, 2 Apr 2019 04:03:25 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10042.outbound.protection.outlook.com [40.107.1.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1EAF1200DB; Tue, 2 Apr 2019 04:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1fOap16I4Zoe/exN/rUCKguK9sRKDyeLliqYtvFL6cE=; b=gAOgOeK6kjFR+TzIp+SK260qPypIXa5t0yXlcFzaPVyOzQIDJlMM8CcOBMgMNHXxB8/joav442IKBy5DMNAlf/Q6mdJO/Fo3T2OKTL6ymDwiroSN5yNtYdkUPsBwWh6cMxRZydtXAy7cCdnmwOWLnweIbuFpcoDb1T9jbulqnSo= Received: from HE1PR0702MB3689.eurprd07.prod.outlook.com (52.133.6.143) by HE1PR0702MB3722.eurprd07.prod.outlook.com (52.133.6.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Tue, 2 Apr 2019 11:03:20 +0000 Received: from HE1PR0702MB3689.eurprd07.prod.outlook.com ([fe80::8016:9a82:4ff3:a264]) by HE1PR0702MB3689.eurprd07.prod.outlook.com ([fe80::8016:9a82:4ff3:a264%6]) with mapi id 15.20.1771.006; Tue, 2 Apr 2019 11:03:20 +0000 From: Gonzalo Camarillo To: Ben Campbell , Andy Hutton CC: "draft-ietf-sipbrandy-osrtp.all@ietf.org" , "sipbrandy@ietf.org" , Alexey Melnikov Thread-Topic: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-osrtp-07 Thread-Index: AQHU48Lbt/qzTjdy9EmtuTAMH59bd6YeFTMAgAqqmgA= Date: Tue, 2 Apr 2019 11:03:20 +0000 Message-ID: References: <72C42C63-D5C4-403D-A895-429CB2238AC3@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.94] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 x-clientproxiedby: HE1PR02CA0112.eurprd02.prod.outlook.com (2603:10a6:7:29::41) To HE1PR0702MB3689.eurprd07.prod.outlook.com (2603:10a6:7:8d::15) authentication-results: spf=none (sender IP is ) smtp.mailfrom=gonzalo.camarillo@ericsson.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 48beb12d-f386-4887-b7b1-08d6b75ad125 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(4534185)(4627221)(201703031133081)(201702281549075)(5600139)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:HE1PR0702MB3722; x-ms-traffictypediagnostic: HE1PR0702MB3722: x-microsoft-antispam-prvs: x-forefront-prvs: 0995196AA2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(346002)(396003)(136003)(39860400002)(199004)(189003)(51914003)(26005)(102836004)(97736004)(86362001)(99286004)(36756003)(8936002)(6306002)(6512007)(186003)(64126003)(386003)(53546011)(6506007)(93886005)(256004)(8676002)(52116002)(81156014)(2906002)(53936002)(81166006)(71200400001)(14444005)(6436002)(31696002)(31686004)(71190400001)(5660300002)(68736007)(99936001)(105586002)(486006)(65826007)(25786009)(66066001)(446003)(54906003)(65806001)(65956001)(6486002)(11346002)(110136005)(305945005)(58126008)(316002)(478600001)(76176011)(966005)(2616005)(476003)(4326008)(6116002)(14454004)(229853002)(106356001)(7736002)(3846002)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3722; H:HE1PR0702MB3689.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: q5KgHEkpQSQbhzuBMln1VqBhN/JN1eRBVFaUsk3lFzNGBiJas4hsFDUbIiyUtO4JwEadUcSKhd70H36M+wRiiiEH/HBO+PZRGzhYo8gZGP4DicvI9/k1ofgA4IvzBOit8SFj0Lg7A0x6rIG0hhFZ++Q8nihSILB0P/p8lJOu51MSUl+qJiogXHB1/G6TFdCIBNUiWpnK1e4PC0LLPRA1dC9B0nC2mvgMI28Y5xUmS/gB/Hc34o9NxXEsiT8N8A5rZXXk62r1Mz01rQvpCxrezBSwJ43YuiVoaK5BtEwjFurCuhOOw7AEK8qmMBFwFYm84IxWxqzjUO977muHxgqUWC5JWBdnlpJr0zFAzkhXrBqbwL1y5YhocsNONwyqiE4xS3I8g691pbgY3eX4ur69eCLQ2zaorHsYpj3z30LVJWE= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RkguChvnAoqoolxQR7O9BWwXoUC4iGF1T" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 48beb12d-f386-4887-b7b1-08d6b75ad125 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2019 11:03:20.6635 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3722 Archived-At: Subject: Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-osrtp-07 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 11:03:29 -0000 --RkguChvnAoqoolxQR7O9BWwXoUC4iGF1T Content-Type: multipart/mixed; boundary="F7r85RtpMrbmvq3ZHLaGHoEnNul8qV5IH"; protected-headers="v1" From: Gonzalo Camarillo To: Ben Campbell , Andy Hutton Cc: "draft-ietf-sipbrandy-osrtp.all@ietf.org" , "sipbrandy@ietf.org" , Alexey Melnikov Message-ID: Subject: Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-osrtp-07 References: <72C42C63-D5C4-403D-A895-429CB2238AC3@nostrum.com> In-Reply-To: --F7r85RtpMrbmvq3ZHLaGHoEnNul8qV5IH Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Andy, authors, could you please let Alexey when he should expect a new revision of this draft that addresses Ben's point below? Cheers, Gonzalo On 26-Mar-19 18:10, Ben Campbell wrote: > (+Alexey, who will take over SIPBRANDY when I step down as AD) >=20 > Hi, >=20 > Thanks for the response. This does not quite address my main substantiv= e comment. It does address everything else :-) >=20 > Please see comment in line. >=20 > Thanks! >=20 > Ben. >=20 >> On Mar 26, 2019, at 11:58 AM, Andy Hutton = wrote: >> >> I submitted an update in response to Ben's comments - >> https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-08 >> >> With regard to Ben's comment on the relaxing of the authentication >> requirement then this is consistent with the Opportunistic Security >> RFC 7435 and I added a reference to this as clarification. >=20 > If I recall correctly, RFC 7435 does not discuss scenarios with separat= e signaling and media channels, and how OS applies to each channel. I was= looking more for something about the impacts of this =E2=80=9Crelaxation= =E2=80=9D specific to these sorts of scenarios with dtls-srtp and sdes, a= nd resulting assurances. >=20 > For example, dtls-srtp with no authentication does not give you assuran= ces about who you are talking to, but it still allows encryption. SDES wi= thout encryption lets an eavesdropper potentially learn the encryption ke= ys, etc. SDES with transport level protection (e.g. SIPS) protects from = off-path eavesdroppers, but allows proxies and b2bua=E2=80=99s in the sig= naling path to learn the encryption keys. >=20 >=20 >> >> Hopefully we can get this to RFC status now. >> >> Regards >> Andy >> >> On Mon, 25 Mar 2019 at 22:26, Andy Hutton = wrote: >>> >>> Sorry about the delay. >>> >>> See below. >>> >>> I will update the draft. >>> >>> Andy >>> >>> On Fri, 15 Feb 2019 at 08:46, Gonzalo Camarillo >>> wrote: >>>> >>>> Thanks for the quick review, Ben! >>>> >>>> Authors, please address Ben's comments below. >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >>>> On 14-Feb-19 22:46, Ben Campbell wrote: >>>>> Hi, >>>>> >>>>> This is my AD Evaluation of draft-ietf-sipbrandy-osrtp-07. >>>>> >>>>> Thank you for a readable and easy to understand document.There is o= ne comment I would like to resolve prior to IETF LC. The others can be re= solved along with any last call feedback. >>>>> >>>>> *** Please resolve prior to IETF LC *** >>>>> >>>>> =C2=A74: The relaxation of authentication requirements for DTLS-SRT= P and SDES could use some elaboration on why this acceptable. I _think_ t= he answer is that, since OSRTP doesn=E2=80=99t guaranty authentication, t= here=E2=80=99s no need for such a guaranty from the signaling channel. Is= that correct? >>>>> >>>>> OTOH, =C2=A71 says "third mode for security between "cleartext=E2=80= =9D and "comprehensive protection" that allows encryption and authenticat= ion to be used if supported=E2=80=A6=E2=80=9D. That suggests that that au= thentication is sometimes provided. Is there a distinction between the au= thenticated case and unauthenticated case that should be mentioned somewh= ere? (For example, is there a need to indicate the distinction to the use= r?) >>>>> >>> >>> $1 should I think say "allows encryption and authenticated media" but= >>> I cannot remember why we said the signalling authentication >>> requirements are relaxed this has been in the draft from day 1 and I >>> guess it is consistent with the best effort approach. >>> >>> Anyone else want to comment? >>> >>> >>>>> *** Other Substantive Comments *** >>>>> >>>>> =C2=A72: Please use the new boilerplate from RFC 8174. >>> >>> Will do. >>> >>>>> >>>>> =C2=A73.1: Please clarify that that the offer can contain more than= one key management attribute. This is mentioned in =C2=A73.1, but not ac= tually in the section on generating the offer. >>> >>> Will do. >>> >>>>> >>>>> *** Editorial Comments *** >>>>> >>>>> =C2=A73: "As discussed in [RFC7435], this is >>>>> the "comprehensive protection" for media mode.=E2=80=9D >>>>> s/this/that >>> >>> Thanks >>> >>>>> >>>>> =C2=A73.4: "meaning that the decision to >>>>> create an OSRTP type offer or something else should not be influenc= ed=E2=80=9D >>>>> That=E2=80=99s referring to the decision to create a _new_ offer, r= ight? Not the original offer? >>> >>> Correct. >>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Sipbrandy mailing list >>>>> Sipbrandy@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipbrandy >>>>> >>>> _______________________________________________ >>>> Sipbrandy mailing list >>>> Sipbrandy@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipbrandy >=20 --F7r85RtpMrbmvq3ZHLaGHoEnNul8qV5IH-- --RkguChvnAoqoolxQR7O9BWwXoUC4iGF1T Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERcQuFjA9XQWMKrc40TNQmHA/hzYFAlyjQXQACgkQ0TNQmHA/ hzb8nAgAyMqAKfa0ROp/gaipK9VNLGx0zvUsj8/vyzK8GsEyglRt2NG08WeKeBiZ gHbQl9ukUDphEYfY6bzgGTGIxJzXE7cV9uiQ+lflWw9VBZFdqSLvmlIkwoS+Vl+i JCM0eQYKxI4o/kL40d8+1tqqjlnFCVBUPhFC6t3yUDvzpVySxXUkIB+3ZO9ZvP0i fHQgrXchTyZyVwhdmB6tRZRjJgtlUJwbSYP3/w2SrUzoPjXgGulM1BEoU4wZuPLM Ztg6kyTD8tiTflb3LsxrTRRmFn8F2iWkwVl53wNq1prx7hPbdbAHwx6r8NMU2sa7 MQAchWL9nSFdtjhwaC4c07AYwJg7mg== =2CU8 -----END PGP SIGNATURE----- --RkguChvnAoqoolxQR7O9BWwXoUC4iGF1T-- From nobody Tue Apr 2 06:51:09 2019 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6181120128; Tue, 2 Apr 2019 06:51:08 -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 145iJM546I2M; Tue, 2 Apr 2019 06:51:04 -0700 (PDT) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 E225D12010E; Tue, 2 Apr 2019 06:51:03 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id g187so7797098vsc.8; Tue, 02 Apr 2019 06:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9Av1Oa38C6FDCCnyFAQfE98b6mbJ7MeQwrjggasq2uQ=; b=FVpv3Fjj33TEkMcgAJmvOSNz6kjkHjb8k1Uzwn71eAZ+unhIV9VKrrBVmBivMfMxiv Bk0/cVF8s+dG7XREjfXp6Aokxl1Z9dknFSmynKD8UwW0Nihpb6dfdtemRN0vFG6YcO+M ZxfBerYUzyN/v49t44U9FJpsqZyv1fI/D+3Z9YuCG1rKWMc5MpWqCh8B4U2rlDqNpiMV mn7SRpaWEfRygoAKSUqraJQvXOg+R9NwufsTbJkZs+YM3pQGurK6UwgFGBwWItVjjq0e ASqG3uyiYAUiLxUYTMXy1RwRRqMUMsCf1guIHCW2ELit84UbfItgHZWvsYyWjU6SZqn4 3zBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9Av1Oa38C6FDCCnyFAQfE98b6mbJ7MeQwrjggasq2uQ=; b=OU36wyDyfWBNHO7T6nENwv8uRX07Aqh/jPX8HdslQzze7Nk4MSs3AreOsk6Lkhzr0u AMPowciqLHpA3YLZTby8qFw66RyuufaKgDUzDa8MRtVa6AEYjtkz/VM2HnyaDzej+dTD vtQxI1cjSVnhRmoaKyH0kez2ANBrKyx8HIDbNAWHkDuUPI0brLHTR6L5WfsiNdaxtiuU H+LKdJYTlT+IxkDG7nWc17zcGBRRiiutT/T/6jkjwt0GQfwlYGXavn+u6/xkqU9SZJRC E8cTaw+qMgnXJgiGqzVTXXWaQ0yFPVchCRMK1hWQK0ff2LGnUXS7qrNB8gDJbUpzPQVM kqqw== X-Gm-Message-State: APjAAAW+dlO60QXASFkOeFObpDuBD7bjSJfvkqxgH4saov1cincX0zMt /4H8E7HaxhGM3pqYq3QArAUQLhC78nUu2P1gavU= X-Google-Smtp-Source: APXvYqytG18eAcDawOrhLuDB5rNKR1S96wxXqfgIt139YwjBClrxQ7DC6Q800CWm+C8iFOFD+hg0XG5/RrW8wAbV1cI= X-Received: by 2002:a67:e3ca:: with SMTP id k10mr38563604vsm.47.1554213062954; Tue, 02 Apr 2019 06:51:02 -0700 (PDT) MIME-Version: 1.0 References: <72C42C63-D5C4-403D-A895-429CB2238AC3@nostrum.com> In-Reply-To: From: Andy Hutton Date: Tue, 2 Apr 2019 14:50:51 +0100 Message-ID: To: Gonzalo Camarillo Cc: Ben Campbell , "draft-ietf-sipbrandy-osrtp.all@ietf.org" , "sipbrandy@ietf.org" , Alexey Melnikov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-osrtp-07 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 13:51:09 -0000 I believe all Ben's points are addressed in the draft I submitted last week https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-08 Regards Andy On Tue, 2 Apr 2019 at 12:03, Gonzalo Camarillo wrote: > > Hi Andy, authors, > > could you please let Alexey when he should expect a new revision of this > draft that addresses Ben's point below? > > Cheers, > > Gonzalo > > On 26-Mar-19 18:10, Ben Campbell wrote: > > (+Alexey, who will take over SIPBRANDY when I step down as AD) > > > > Hi, > > > > Thanks for the response. This does not quite address my main substantiv= e comment. It does address everything else :-) > > > > Please see comment in line. > > > > Thanks! > > > > Ben. > > > >> On Mar 26, 2019, at 11:58 AM, Andy Hutton = wrote: > >> > >> I submitted an update in response to Ben's comments - > >> https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-08 > >> > >> With regard to Ben's comment on the relaxing of the authentication > >> requirement then this is consistent with the Opportunistic Security > >> RFC 7435 and I added a reference to this as clarification. > > > > If I recall correctly, RFC 7435 does not discuss scenarios with separat= e signaling and media channels, and how OS applies to each channel. I was l= ooking more for something about the impacts of this =E2=80=9Crelaxation=E2= =80=9D specific to these sorts of scenarios with dtls-srtp and sdes, and re= sulting assurances. > > > > For example, dtls-srtp with no authentication does not give you assuran= ces about who you are talking to, but it still allows encryption. SDES with= out encryption lets an eavesdropper potentially learn the encryption keys, = etc. SDES with transport level protection (e.g. SIPS) protects from off-pa= th eavesdroppers, but allows proxies and b2bua=E2=80=99s in the signaling p= ath to learn the encryption keys. > > > > > >> > >> Hopefully we can get this to RFC status now. > >> > >> Regards > >> Andy > >> > >> On Mon, 25 Mar 2019 at 22:26, Andy Hutton = wrote: > >>> > >>> Sorry about the delay. > >>> > >>> See below. > >>> > >>> I will update the draft. > >>> > >>> Andy > >>> > >>> On Fri, 15 Feb 2019 at 08:46, Gonzalo Camarillo > >>> wrote: > >>>> > >>>> Thanks for the quick review, Ben! > >>>> > >>>> Authors, please address Ben's comments below. > >>>> > >>>> Cheers, > >>>> > >>>> Gonzalo > >>>> > >>>> On 14-Feb-19 22:46, Ben Campbell wrote: > >>>>> Hi, > >>>>> > >>>>> This is my AD Evaluation of draft-ietf-sipbrandy-osrtp-07. > >>>>> > >>>>> Thank you for a readable and easy to understand document.There is o= ne comment I would like to resolve prior to IETF LC. The others can be reso= lved along with any last call feedback. > >>>>> > >>>>> *** Please resolve prior to IETF LC *** > >>>>> > >>>>> =C2=A74: The relaxation of authentication requirements for DTLS-SRT= P and SDES could use some elaboration on why this acceptable. I _think_ the= answer is that, since OSRTP doesn=E2=80=99t guaranty authentication, there= =E2=80=99s no need for such a guaranty from the signaling channel. Is that = correct? > >>>>> > >>>>> OTOH, =C2=A71 says "third mode for security between "cleartext=E2= =80=9D and "comprehensive protection" that allows encryption and authentica= tion to be used if supported=E2=80=A6=E2=80=9D. That suggests that that aut= hentication is sometimes provided. Is there a distinction between the authe= nticated case and unauthenticated case that should be mentioned somewhere? = (For example, is there a need to indicate the distinction to the user?) > >>>>> > >>> > >>> $1 should I think say "allows encryption and authenticated media" but > >>> I cannot remember why we said the signalling authentication > >>> requirements are relaxed this has been in the draft from day 1 and I > >>> guess it is consistent with the best effort approach. > >>> > >>> Anyone else want to comment? > >>> > >>> > >>>>> *** Other Substantive Comments *** > >>>>> > >>>>> =C2=A72: Please use the new boilerplate from RFC 8174. > >>> > >>> Will do. > >>> > >>>>> > >>>>> =C2=A73.1: Please clarify that that the offer can contain more than= one key management attribute. This is mentioned in =C2=A73.1, but not actu= ally in the section on generating the offer. > >>> > >>> Will do. > >>> > >>>>> > >>>>> *** Editorial Comments *** > >>>>> > >>>>> =C2=A73: "As discussed in [RFC7435], this is > >>>>> the "comprehensive protection" for media mode.=E2=80=9D > >>>>> s/this/that > >>> > >>> Thanks > >>> > >>>>> > >>>>> =C2=A73.4: "meaning that the decision to > >>>>> create an OSRTP type offer or something else should not be influenc= ed=E2=80=9D > >>>>> That=E2=80=99s referring to the decision to create a _new_ offer, r= ight? Not the original offer? > >>> > >>> Correct. > >>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Sipbrandy mailing list > >>>>> Sipbrandy@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sipbrandy > >>>>> > >>>> _______________________________________________ > >>>> Sipbrandy mailing list > >>>> Sipbrandy@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sipbrandy > > > From nobody Tue Apr 2 06:56:31 2019 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3065C120153; Tue, 2 Apr 2019 06:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=ericsson.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 b-0WrlYRQRh3; Tue, 2 Apr 2019 06:56:20 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130049.outbound.protection.outlook.com [40.107.13.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D96CC12011E; Tue, 2 Apr 2019 06:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rC78RiXY4MrKQWIJ/jYHmX+ywTocBWkn96Ww3POtsgM=; b=mIRrZPDsg//SrhCGLjy9iQGbLDea1Na0JX9pBQCw3pnc5jAfizC0ApsRY/uFPGu6bdfyqT9I5jDY83lSLsBECPOYMsMbI8f6W8cv6QkdoHPTwC4oPi3g5n+fgclRilnBT5wQM1igYraFaaXz4I6NfClNziPTy41QdYE9mKWYevg= Received: from HE1PR0702MB3689.eurprd07.prod.outlook.com (52.133.6.143) by HE1PR0702MB3530.eurprd07.prod.outlook.com (52.133.5.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.8; Tue, 2 Apr 2019 13:55:44 +0000 Received: from HE1PR0702MB3689.eurprd07.prod.outlook.com ([fe80::8016:9a82:4ff3:a264]) by HE1PR0702MB3689.eurprd07.prod.outlook.com ([fe80::8016:9a82:4ff3:a264%6]) with mapi id 15.20.1771.006; Tue, 2 Apr 2019 13:55:44 +0000 From: Gonzalo Camarillo To: Andy Hutton CC: Ben Campbell , "sipbrandy@ietf.org" , "draft-ietf-sipbrandy-osrtp.all@ietf.org" , Alexey Melnikov Thread-Topic: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-osrtp-07 Thread-Index: AQHU48Lbt/qzTjdy9EmtuTAMH59bd6YeFTMAgAqqmgCAAC7XgIAAAVkA Date: Tue, 2 Apr 2019 13:55:44 +0000 Message-ID: <741719ee-bbc6-adaf-a036-8fdd655e470f@ericsson.com> References: <72C42C63-D5C4-403D-A895-429CB2238AC3@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.94] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 x-clientproxiedby: HE1PR0102CA0003.eurprd01.prod.exchangelabs.com (2603:10a6:7:14::16) To HE1PR0702MB3689.eurprd07.prod.outlook.com (2603:10a6:7:8d::15) authentication-results: spf=none (sender IP is ) smtp.mailfrom=gonzalo.camarillo@ericsson.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 17e0d3c9-cfc3-49c6-6243-08d6b772e679 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0702MB3530; x-ms-traffictypediagnostic: HE1PR0702MB3530: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0995196AA2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(396003)(346002)(366004)(39860400002)(199004)(189003)(51914003)(65826007)(105586002)(36756003)(966005)(11346002)(31686004)(6116002)(4326008)(14454004)(3846002)(446003)(31696002)(86362001)(71190400001)(71200400001)(2906002)(64126003)(76176011)(97736004)(256004)(14444005)(106356001)(68736007)(99286004)(6486002)(53936002)(26005)(52116002)(186003)(386003)(6506007)(53546011)(8936002)(478600001)(81166006)(25786009)(5660300002)(6512007)(6306002)(102836004)(6246003)(93886005)(2616005)(229853002)(476003)(316002)(58126008)(54906003)(66066001)(6436002)(65956001)(65806001)(7736002)(8676002)(6916009)(81156014)(305945005)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3530; H:HE1PR0702MB3689.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: SdDcEaq9kKectNrppzFwFQaUoD4R8Yo4huiI7cF0+3KRrQ0dmIOvjcs7NQ8Ku8+0kVr5pa6zeKV3/BzP/TCKJOnCLtxV6ST6d3fFd/QhEt78zxOAf0Lbc/+1ccqXHeIOivT9lEQtElYIMHPMg1ZpaTINmxaliNulzWmAtxXOIFewC+rY1vprpvkkFNUU5mYI8ELcIppWd1O8al/nBOoQwhsV614elolrA52IRnEzfYkwwPTpPKgQUCVdUZPhIky47+fC73Nhrsh3KgE+g1K7GUFLapEVETzllPMukyGnZ1Hk3cgeMCHConNFiIHTFsLt22a7ux7ea2Jef5t1aRK1dD1dtgFJ+5v/Ki8W3scbFH51EFxflJka21y+3KHAXTX3IrBAg0Bv4zvGm3B/bADu56cY6NRq2juKT6SrI1KAw9g= Content-Type: text/plain; charset="utf-8" Content-ID: <7DEEA7F8D621DA4891772AD4A03CADC2@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 17e0d3c9-cfc3-49c6-6243-08d6b772e679 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2019 13:55:44.3195 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3530 Archived-At: Subject: Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-osrtp-07 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 13:56:24 -0000 SGkgQW5keSwNCg0KQmVuJ3MgcmVzcG9uc2UgYmVsb3cgaW5kaWNhdGVzIHRoYXQgaGlzIG1haW4g c3Vic3RhbnRpdmUgY29tbWVudCB3YXMgbm90DQphZGRyZXNzZWQgaW4gdGhlIHJldmlzaW9uIHlv dSBzdWJtaXR0ZWQgbGFzdCB3ZWVrLiBDb3VsZCB5b3UgcGxlYXNlIGxvb2sNCmludG8gaXQgYW5k IGdldCBiYWNrIHRvIEJlbj8gVGhhbmtzIQ0KDQo+PiBXaXRoIHJlZ2FyZCB0byBCZW4ncyBjb21t ZW50IG9uIHRoZSByZWxheGluZyBvZiB0aGUgYXV0aGVudGljYXRpb24gDQo+PiByZXF1aXJlbWVu dCB0aGVuIHRoaXMgaXMgY29uc2lzdGVudCB3aXRoIHRoZSBPcHBvcnR1bmlzdGljDQo+PiBTZWN1 cml0eSBSRkMgNzQzNSBhbmQgSSBhZGRlZCBhIHJlZmVyZW5jZSB0byB0aGlzIGFzDQo+PiBjbGFy aWZpY2F0aW9uLg0KPiANCj4gSWYgSSByZWNhbGwgY29ycmVjdGx5LCBSRkMgNzQzNSBkb2VzIG5v dCBkaXNjdXNzIHNjZW5hcmlvcyB3aXRoDQo+IHNlcGFyYXRlIHNpZ25hbGluZyBhbmQgbWVkaWEg Y2hhbm5lbHMsIGFuZCBob3cgT1MgYXBwbGllcyB0byBlYWNoDQo+IGNoYW5uZWwuIEkgd2FzIGxv b2tpbmcgbW9yZSBmb3Igc29tZXRoaW5nIGFib3V0IHRoZSBpbXBhY3RzIG9mIHRoaXMNCj4g4oCc cmVsYXhhdGlvbuKAnSBzcGVjaWZpYyB0byB0aGVzZSBzb3J0cyBvZiBzY2VuYXJpb3Mgd2l0aCBk dGxzLXNydHAgYW5kDQo+IHNkZXMsIGFuZCByZXN1bHRpbmcgYXNzdXJhbmNlcy4NCj4gDQo+IEZv ciBleGFtcGxlLCBkdGxzLXNydHAgd2l0aCBubyBhdXRoZW50aWNhdGlvbiBkb2VzIG5vdCBnaXZl IHlvdQ0KPiBhc3N1cmFuY2VzIGFib3V0IHdobyB5b3UgYXJlIHRhbGtpbmcgdG8sIGJ1dCBpdCBz dGlsbCBhbGxvd3MNCj4gZW5jcnlwdGlvbi4gU0RFUyB3aXRob3V0IGVuY3J5cHRpb24gbGV0cyBh biBlYXZlc2Ryb3BwZXIgcG90ZW50aWFsbHkNCj4gbGVhcm4gdGhlIGVuY3J5cHRpb24ga2V5cywg ZXRjLiBTREVTIHdpdGggdHJhbnNwb3J0IGxldmVsIHByb3RlY3Rpb24NCj4gKGUuZy4gU0lQUykg cHJvdGVjdHMgZnJvbSBvZmYtcGF0aCBlYXZlc2Ryb3BwZXJzLCBidXQgYWxsb3dzIHByb3hpZXMN Cj4gYW5kIGIyYnVh4oCZcyBpbiB0aGUgc2lnbmFsaW5nIHBhdGggdG8gbGVhcm4gdGhlIGVuY3J5 cHRpb24ga2V5cy4NCg0KDQpDaGVlcnMsDQoNCkdvbnphbG8NCg0KT24gMDItQXByLTE5IDE2OjUw LCBBbmR5IEh1dHRvbiB3cm90ZToNCj4gSSBiZWxpZXZlIGFsbCBCZW4ncyBwb2ludHMgYXJlIGFk ZHJlc3NlZCBpbiB0aGUgZHJhZnQgSSBzdWJtaXR0ZWQNCj4gbGFzdCB3ZWVrIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNpcGJyYW5keS1vc3J0cC0wOA0KPiANCj4gUmVn YXJkcyBBbmR5DQo+IA0KPiBPbiBUdWUsIDIgQXByIDIwMTkgYXQgMTI6MDMsIEdvbnphbG8gQ2Ft YXJpbGxvIA0KPiA8Z29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+IA0K Pj4gSGkgQW5keSwgYXV0aG9ycywNCj4+IA0KPj4gY291bGQgeW91IHBsZWFzZSBsZXQgQWxleGV5 IHdoZW4gaGUgc2hvdWxkIGV4cGVjdCBhIG5ldyByZXZpc2lvbiBvZg0KPj4gdGhpcyBkcmFmdCB0 aGF0IGFkZHJlc3NlcyBCZW4ncyBwb2ludCBiZWxvdz8NCj4+IA0KPj4gQ2hlZXJzLA0KPj4gDQo+ PiBHb256YWxvDQo+PiANCj4+IE9uIDI2LU1hci0xOSAxODoxMCwgQmVuIENhbXBiZWxsIHdyb3Rl Og0KPj4+ICgrQWxleGV5LCB3aG8gd2lsbCB0YWtlIG92ZXIgU0lQQlJBTkRZIHdoZW4gSSBzdGVw IGRvd24gYXMgQUQpDQo+Pj4gDQo+Pj4gSGksDQo+Pj4gDQo+Pj4gVGhhbmtzIGZvciB0aGUgcmVz cG9uc2UuIFRoaXMgZG9lcyBub3QgcXVpdGUgYWRkcmVzcyBteSBtYWluDQo+Pj4gc3Vic3RhbnRp dmUgY29tbWVudC4gSXQgZG9lcyBhZGRyZXNzIGV2ZXJ5dGhpbmcgZWxzZSA6LSkNCj4+PiANCj4+ PiBQbGVhc2Ugc2VlIGNvbW1lbnQgaW4gbGluZS4NCj4+PiANCj4+PiBUaGFua3MhDQo+Pj4gDQo+ Pj4gQmVuLg0KPj4+IA0KPj4+PiBPbiBNYXIgMjYsIDIwMTksIGF0IDExOjU4IEFNLCBBbmR5IEh1 dHRvbg0KPj4+PiA8YW5keWh1dHRvbi5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+ PiBJIHN1Ym1pdHRlZCBhbiB1cGRhdGUgaW4gcmVzcG9uc2UgdG8gQmVuJ3MgY29tbWVudHMgLSAN Cj4+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2lwYnJhbmR5LW9z cnRwLTA4DQo+Pj4+IA0KPj4+PiBXaXRoIHJlZ2FyZCB0byBCZW4ncyBjb21tZW50IG9uIHRoZSBy ZWxheGluZyBvZiB0aGUNCj4+Pj4gYXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnQgdGhlbiB0aGlz IGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUNCj4+Pj4gT3Bwb3J0dW5pc3RpYyBTZWN1cml0eSBSRkMg NzQzNSBhbmQgSSBhZGRlZCBhIHJlZmVyZW5jZSB0byB0aGlzDQo+Pj4+IGFzIGNsYXJpZmljYXRp b24uDQo+Pj4gDQo+Pj4gSWYgSSByZWNhbGwgY29ycmVjdGx5LCBSRkMgNzQzNSBkb2VzIG5vdCBk aXNjdXNzIHNjZW5hcmlvcyB3aXRoDQo+Pj4gc2VwYXJhdGUgc2lnbmFsaW5nIGFuZCBtZWRpYSBj aGFubmVscywgYW5kIGhvdyBPUyBhcHBsaWVzIHRvIGVhY2gNCj4+PiBjaGFubmVsLiBJIHdhcyBs b29raW5nIG1vcmUgZm9yIHNvbWV0aGluZyBhYm91dCB0aGUgaW1wYWN0cyBvZg0KPj4+IHRoaXMg 4oCccmVsYXhhdGlvbuKAnSBzcGVjaWZpYyB0byB0aGVzZSBzb3J0cyBvZiBzY2VuYXJpb3Mgd2l0 aA0KPj4+IGR0bHMtc3J0cCBhbmQgc2RlcywgYW5kIHJlc3VsdGluZyBhc3N1cmFuY2VzLg0KPj4+ IA0KPj4+IEZvciBleGFtcGxlLCBkdGxzLXNydHAgd2l0aCBubyBhdXRoZW50aWNhdGlvbiBkb2Vz IG5vdCBnaXZlIHlvdQ0KPj4+IGFzc3VyYW5jZXMgYWJvdXQgd2hvIHlvdSBhcmUgdGFsa2luZyB0 bywgYnV0IGl0IHN0aWxsIGFsbG93cw0KPj4+IGVuY3J5cHRpb24uIFNERVMgd2l0aG91dCBlbmNy eXB0aW9uIGxldHMgYW4gZWF2ZXNkcm9wcGVyDQo+Pj4gcG90ZW50aWFsbHkgbGVhcm4gdGhlIGVu Y3J5cHRpb24ga2V5cywgZXRjLiBTREVTIHdpdGggdHJhbnNwb3J0DQo+Pj4gbGV2ZWwgcHJvdGVj dGlvbiAgKGUuZy4gU0lQUykgcHJvdGVjdHMgZnJvbSBvZmYtcGF0aA0KPj4+IGVhdmVzZHJvcHBl cnMsIGJ1dCBhbGxvd3MgcHJveGllcyBhbmQgYjJidWHigJlzIGluIHRoZSBzaWduYWxpbmcNCj4+ PiBwYXRoIHRvIGxlYXJuIHRoZSBlbmNyeXB0aW9uIGtleXMuDQo+Pj4gDQo+Pj4gDQo+Pj4+IA0K Pj4+PiBIb3BlZnVsbHkgd2UgY2FuIGdldCB0aGlzIHRvIFJGQyBzdGF0dXMgbm93Lg0KPj4+PiAN Cj4+Pj4gUmVnYXJkcyBBbmR5DQo+Pj4+IA0KPj4+PiBPbiBNb24sIDI1IE1hciAyMDE5IGF0IDIy OjI2LCBBbmR5IEh1dHRvbg0KPj4+PiA8YW5keWh1dHRvbi5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6 DQo+Pj4+PiANCj4+Pj4+IFNvcnJ5IGFib3V0IHRoZSBkZWxheS4NCj4+Pj4+IA0KPj4+Pj4gU2Vl IGJlbG93Lg0KPj4+Pj4gDQo+Pj4+PiBJIHdpbGwgdXBkYXRlIHRoZSBkcmFmdC4NCj4+Pj4+IA0K Pj4+Pj4gQW5keQ0KPj4+Pj4gDQo+Pj4+PiBPbiBGcmksIDE1IEZlYiAyMDE5IGF0IDA4OjQ2LCBH b256YWxvIENhbWFyaWxsbyANCj4+Pj4+IDxnb256YWxvLmNhbWFyaWxsb0Blcmljc3Nvbi5jb20+ IHdyb3RlOg0KPj4+Pj4+IA0KPj4+Pj4+IFRoYW5rcyBmb3IgdGhlIHF1aWNrIHJldmlldywgQmVu IQ0KPj4+Pj4+IA0KPj4+Pj4+IEF1dGhvcnMsIHBsZWFzZSBhZGRyZXNzIEJlbidzIGNvbW1lbnRz IGJlbG93Lg0KPj4+Pj4+IA0KPj4+Pj4+IENoZWVycywNCj4+Pj4+PiANCj4+Pj4+PiBHb256YWxv DQo+Pj4+Pj4gDQo+Pj4+Pj4gT24gMTQtRmViLTE5IDIyOjQ2LCBCZW4gQ2FtcGJlbGwgd3JvdGU6 DQo+Pj4+Pj4+IEhpLA0KPj4+Pj4+PiANCj4+Pj4+Pj4gVGhpcyBpcyBteSBBRCBFdmFsdWF0aW9u IG9mDQo+Pj4+Pj4+IGRyYWZ0LWlldGYtc2lwYnJhbmR5LW9zcnRwLTA3Lg0KPj4+Pj4+PiANCj4+ Pj4+Pj4gVGhhbmsgeW91IGZvciBhIHJlYWRhYmxlIGFuZCBlYXN5IHRvIHVuZGVyc3RhbmQNCj4+ Pj4+Pj4gZG9jdW1lbnQuVGhlcmUgaXMgb25lIGNvbW1lbnQgSSB3b3VsZCBsaWtlIHRvIHJlc29s dmUNCj4+Pj4+Pj4gcHJpb3IgdG8gSUVURiBMQy4gVGhlIG90aGVycyBjYW4gYmUgcmVzb2x2ZWQg YWxvbmcgd2l0aA0KPj4+Pj4+PiBhbnkgbGFzdCBjYWxsIGZlZWRiYWNrLg0KPj4+Pj4+PiANCj4+ Pj4+Pj4gKioqIFBsZWFzZSByZXNvbHZlIHByaW9yIHRvIElFVEYgTEMgKioqDQo+Pj4+Pj4+IA0K Pj4+Pj4+PiDCpzQ6IFRoZSByZWxheGF0aW9uIG9mIGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50 cyBmb3INCj4+Pj4+Pj4gRFRMUy1TUlRQIGFuZCBTREVTIGNvdWxkIHVzZSBzb21lIGVsYWJvcmF0 aW9uIG9uIHdoeSB0aGlzDQo+Pj4+Pj4+IGFjY2VwdGFibGUuIEkgX3RoaW5rXyB0aGUgYW5zd2Vy IGlzIHRoYXQsIHNpbmNlIE9TUlRQDQo+Pj4+Pj4+IGRvZXNu4oCZdCBndWFyYW50eSBhdXRoZW50 aWNhdGlvbiwgdGhlcmXigJlzIG5vIG5lZWQgZm9yIHN1Y2gNCj4+Pj4+Pj4gYSBndWFyYW50eSBm cm9tIHRoZSBzaWduYWxpbmcgY2hhbm5lbC4gSXMgdGhhdCBjb3JyZWN0Pw0KPj4+Pj4+PiANCj4+ Pj4+Pj4gT1RPSCwgwqcxIHNheXMgInRoaXJkIG1vZGUgZm9yIHNlY3VyaXR5IGJldHdlZW4NCj4+ Pj4+Pj4gImNsZWFydGV4dOKAnSBhbmQgImNvbXByZWhlbnNpdmUgcHJvdGVjdGlvbiIgdGhhdCBh bGxvd3MNCj4+Pj4+Pj4gZW5jcnlwdGlvbiBhbmQgYXV0aGVudGljYXRpb24gdG8gYmUgdXNlZCBp ZiBzdXBwb3J0ZWTigKbigJ0uDQo+Pj4+Pj4+IFRoYXQgc3VnZ2VzdHMgdGhhdCB0aGF0IGF1dGhl bnRpY2F0aW9uIGlzIHNvbWV0aW1lcw0KPj4+Pj4+PiBwcm92aWRlZC4gSXMgdGhlcmUgYSBkaXN0 aW5jdGlvbiBiZXR3ZWVuIHRoZQ0KPj4+Pj4+PiBhdXRoZW50aWNhdGVkIGNhc2UgYW5kIHVuYXV0 aGVudGljYXRlZCBjYXNlIHRoYXQgc2hvdWxkDQo+Pj4+Pj4+IGJlIG1lbnRpb25lZCBzb21ld2hl cmU/IChGb3IgZXhhbXBsZSwgaXMgdGhlcmUgYSBuZWVkIHRvDQo+Pj4+Pj4+IGluZGljYXRlIHRo ZSBkaXN0aW5jdGlvbiB0byB0aGUgdXNlcj8pDQo+Pj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiAkMSBz aG91bGQgSSB0aGluayBzYXkgImFsbG93cyBlbmNyeXB0aW9uIGFuZCBhdXRoZW50aWNhdGVkDQo+ Pj4+PiBtZWRpYSIgYnV0IEkgY2Fubm90IHJlbWVtYmVyIHdoeSB3ZSBzYWlkIHRoZSBzaWduYWxs aW5nDQo+Pj4+PiBhdXRoZW50aWNhdGlvbiByZXF1aXJlbWVudHMgYXJlIHJlbGF4ZWQgdGhpcyBo YXMgYmVlbiBpbiB0aGUNCj4+Pj4+IGRyYWZ0IGZyb20gZGF5IDEgYW5kIEkgZ3Vlc3MgaXQgaXMg Y29uc2lzdGVudCB3aXRoIHRoZSBiZXN0DQo+Pj4+PiBlZmZvcnQgYXBwcm9hY2guDQo+Pj4+PiAN Cj4+Pj4+IEFueW9uZSBlbHNlIHdhbnQgdG8gY29tbWVudD8NCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+ Pj4+ICoqKiBPdGhlciBTdWJzdGFudGl2ZSBDb21tZW50cyAqKioNCj4+Pj4+Pj4gDQo+Pj4+Pj4+ IMKnMjogUGxlYXNlIHVzZSB0aGUgbmV3IGJvaWxlcnBsYXRlIGZyb20gUkZDIDgxNzQuDQo+Pj4+ PiANCj4+Pj4+IFdpbGwgZG8uDQo+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IMKnMy4xOiBQbGVh c2UgY2xhcmlmeSB0aGF0IHRoYXQgdGhlIG9mZmVyIGNhbiBjb250YWluIG1vcmUNCj4+Pj4+Pj4g dGhhbiBvbmUga2V5IG1hbmFnZW1lbnQgYXR0cmlidXRlLiBUaGlzIGlzIG1lbnRpb25lZCBpbg0K Pj4+Pj4+PiDCpzMuMSwgYnV0IG5vdCBhY3R1YWxseSBpbiB0aGUgc2VjdGlvbiBvbiBnZW5lcmF0 aW5nIHRoZQ0KPj4+Pj4+PiBvZmZlci4NCj4+Pj4+IA0KPj4+Pj4gV2lsbCBkby4NCj4+Pj4+IA0K Pj4+Pj4+PiANCj4+Pj4+Pj4gKioqIEVkaXRvcmlhbCBDb21tZW50cyAqKioNCj4+Pj4+Pj4gDQo+ Pj4+Pj4+IMKnMzogIkFzIGRpc2N1c3NlZCBpbiBbUkZDNzQzNV0sIHRoaXMgaXMgdGhlDQo+Pj4+ Pj4+ICJjb21wcmVoZW5zaXZlIHByb3RlY3Rpb24iIGZvciBtZWRpYSBtb2RlLuKAnSBzL3RoaXMv dGhhdA0KPj4+Pj4gDQo+Pj4+PiBUaGFua3MNCj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gwqcz LjQ6ICJtZWFuaW5nIHRoYXQgdGhlIGRlY2lzaW9uIHRvIGNyZWF0ZSBhbiBPU1JUUCB0eXBlDQo+ Pj4+Pj4+IG9mZmVyIG9yIHNvbWV0aGluZyBlbHNlIHNob3VsZCBub3QgYmUgaW5mbHVlbmNlZOKA nSBUaGF04oCZcw0KPj4+Pj4+PiByZWZlcnJpbmcgdG8gdGhlIGRlY2lzaW9uIHRvIGNyZWF0ZSBh IF9uZXdfIG9mZmVyLCByaWdodD8NCj4+Pj4+Pj4gTm90IHRoZSBvcmlnaW5hbCBvZmZlcj8NCj4+ Pj4+IA0KPj4+Pj4gQ29ycmVjdC4NCj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+ IA0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XyBTaXBicmFuZHkNCj4+Pj4+Pj4gbWFpbGluZyBsaXN0IFNpcGJyYW5keUBpZXRmLm9yZyANCj4+ Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBicmFuZHkNCj4+ Pj4+Pj4gDQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18gU2lwYnJhbmR5DQo+Pj4+Pj4gbWFpbGluZyBsaXN0IFNpcGJyYW5keUBpZXRmLm9yZyAN Cj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGJyYW5keQ0K Pj4+IA0KPj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXyBTaXBicmFuZHkgbWFpbGluZw0KPiBsaXN0IFNpcGJyYW5keUBpZXRmLm9yZyANCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBicmFuZHkNCj4gDQo= From nobody Mon Apr 8 03:47:34 2019 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A91120058; Mon, 8 Apr 2019 03:47:32 -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 IsKw3mDGNdEk; Mon, 8 Apr 2019 03:47:30 -0700 (PDT) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 A0945120019; Mon, 8 Apr 2019 03:47:30 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id d5so4131158uan.6; Mon, 08 Apr 2019 03:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2PH3uZ/eNAwCJSbj0uVQsrFqk0mVU0g2saa9+mMTECk=; b=bstrwim131KHMiyTHrwNVd39DB6zeDzbL5wjCEbdVb91vCzMSCODbcg+kbhLmLGhKP u97+URDO8DlFYcWNBN8UY3z0Z3Ns3YIxn9lmaXOnX4b8cO4eT8TiQj/J6jX+7QVkbM7u XpnCLglajYVIo3WEcFu53Ih/Tw6YtiGNgHdWOCJENOhqLEe/1Cr8tCqOEQGXsUZUra5i 6YQllpHjTzK0RLE+BaqH0PwyFG6/MDYbr6x5iezWMKva/34yA1sl62CttO8r5svr2QA5 WCGl7CHRgIK0vk97/l+Xx1rM77ehhn2ZRJQeWO0NpoAncXYan611n9n+c4WnBUSmQusH rAow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2PH3uZ/eNAwCJSbj0uVQsrFqk0mVU0g2saa9+mMTECk=; b=ogY4Lub7FiT3NfbRrYPSBp7/bSSvQHInnw84mQqcLa30ofTtW5pV1NMBp4BDMT+9fJ rntGkwI7cX2a63qyuOBrixckhamx1tgncnh1uiNszy4IBwFfrj5axJMuXBIiTcNULWgv OCtzJuTP5c1LnjFzQg/u/pvyA1mO9LwSlX66MkLhtIuv7++bxp8Vz9rEj6f+Xd/uX8qh O5H+bzuqsRhMAYpn4xgcALQ/OBH+xFA+YLuFDDQwGrU1dlpfhcJY8xELBFjEM34rRD+p RmxWfHzk6YoeDXq86iWI6PmYwHMRvfpimc73Ahpt9JkS64qzCoEspcH3BxU2dh9VntFI nrkg== X-Gm-Message-State: APjAAAWnh7+JtIP0ZhE5DVSu8ZsujJ7yhXRwmxiGADTV27feT99ksGWp 8f9MeLuYZa7NdEAOUJ/yZVcy8wr9b3J7AtrViDc= X-Google-Smtp-Source: APXvYqwEqSCkAov1Tn4xCQUugHz/dIXdgQpVCB3qAUanUrV/jOpbirVImhXV8+CZSjoRS1R5G7BtEQIm15O+k64KmnI= X-Received: by 2002:ab0:6258:: with SMTP id p24mr14896335uao.27.1554720449641; Mon, 08 Apr 2019 03:47:29 -0700 (PDT) MIME-Version: 1.0 References: <72C42C63-D5C4-403D-A895-429CB2238AC3@nostrum.com> <741719ee-bbc6-adaf-a036-8fdd655e470f@ericsson.com> In-Reply-To: <741719ee-bbc6-adaf-a036-8fdd655e470f@ericsson.com> From: Andy Hutton Date: Mon, 8 Apr 2019 11:47:22 +0100 Message-ID: To: Gonzalo Camarillo Cc: Ben Campbell , "sipbrandy@ietf.org" , "draft-ietf-sipbrandy-osrtp.all@ietf.org" , Alexey Melnikov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-osrtp-07 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 10:47:33 -0000 I looked at this again and I am not convinced that any further changes to the draft are needed but if someone wants to suggest text then I can include it in the draft. In the case of SDES the security considerations states that an encrypted signalling channel must still be used so this draft changes nothing with respect to intermediaries and the SDES (RFC 4568) security considerations still apply. Regards Andy On Tue, 2 Apr 2019 at 14:56, Gonzalo Camarillo wrote: > > Hi Andy, > > Ben's response below indicates that his main substantive comment was not > addressed in the revision you submitted last week. Could you please look > into it and get back to Ben? Thanks! > > >> With regard to Ben's comment on the relaxing of the authentication > >> requirement then this is consistent with the Opportunistic > >> Security RFC 7435 and I added a reference to this as > >> clarification. > > > > If I recall correctly, RFC 7435 does not discuss scenarios with > > separate signaling and media channels, and how OS applies to each > > channel. I was looking more for something about the impacts of this > > =E2=80=9Crelaxation=E2=80=9D specific to these sorts of scenarios with = dtls-srtp and > > sdes, and resulting assurances. > > > > For example, dtls-srtp with no authentication does not give you > > assurances about who you are talking to, but it still allows > > encryption. SDES without encryption lets an eavesdropper potentially > > learn the encryption keys, etc. SDES with transport level protection > > (e.g. SIPS) protects from off-path eavesdroppers, but allows proxies > > and b2bua=E2=80=99s in the signaling path to learn the encryption keys. > > > Cheers, > > Gonzalo > > On 02-Apr-19 16:50, Andy Hutton wrote: > > I believe all Ben's points are addressed in the draft I submitted > > last week https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-08 > > > > Regards Andy > > > > On Tue, 2 Apr 2019 at 12:03, Gonzalo Camarillo > > wrote: > >> > >> Hi Andy, authors, > >> > >> could you please let Alexey when he should expect a new revision of > >> this draft that addresses Ben's point below? > >> > >> Cheers, > >> > >> Gonzalo > >> > >> On 26-Mar-19 18:10, Ben Campbell wrote: > >>> (+Alexey, who will take over SIPBRANDY when I step down as AD) > >>> > >>> Hi, > >>> > >>> Thanks for the response. This does not quite address my main > >>> substantive comment. It does address everything else :-) > >>> > >>> Please see comment in line. > >>> > >>> Thanks! > >>> > >>> Ben. > >>> > >>>> On Mar 26, 2019, at 11:58 AM, Andy Hutton > >>>> wrote: > >>>> > >>>> I submitted an update in response to Ben's comments - > >>>> https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-08 > >>>> > >>>> With regard to Ben's comment on the relaxing of the > >>>> authentication requirement then this is consistent with the > >>>> Opportunistic Security RFC 7435 and I added a reference to this > >>>> as clarification. > >>> > >>> If I recall correctly, RFC 7435 does not discuss scenarios with > >>> separate signaling and media channels, and how OS applies to each > >>> channel. I was looking more for something about the impacts of > >>> this =E2=80=9Crelaxation=E2=80=9D specific to these sorts of scenario= s with > >>> dtls-srtp and sdes, and resulting assurances. > >>> > >>> For example, dtls-srtp with no authentication does not give you > >>> assurances about who you are talking to, but it still allows > >>> encryption. SDES without encryption lets an eavesdropper > >>> potentially learn the encryption keys, etc. SDES with transport > >>> level protection (e.g. SIPS) protects from off-path > >>> eavesdroppers, but allows proxies and b2bua=E2=80=99s in the signalin= g > >>> path to learn the encryption keys. > >>> > >>> > >>>> > >>>> Hopefully we can get this to RFC status now. > >>>> > >>>> Regards Andy > >>>> > >>>> On Mon, 25 Mar 2019 at 22:26, Andy Hutton > >>>> wrote: > >>>>> > >>>>> Sorry about the delay. > >>>>> > >>>>> See below. > >>>>> > >>>>> I will update the draft. > >>>>> > >>>>> Andy > >>>>> > >>>>> On Fri, 15 Feb 2019 at 08:46, Gonzalo Camarillo > >>>>> wrote: > >>>>>> > >>>>>> Thanks for the quick review, Ben! > >>>>>> > >>>>>> Authors, please address Ben's comments below. > >>>>>> > >>>>>> Cheers, > >>>>>> > >>>>>> Gonzalo > >>>>>> > >>>>>> On 14-Feb-19 22:46, Ben Campbell wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> This is my AD Evaluation of > >>>>>>> draft-ietf-sipbrandy-osrtp-07. > >>>>>>> > >>>>>>> Thank you for a readable and easy to understand > >>>>>>> document.There is one comment I would like to resolve > >>>>>>> prior to IETF LC. The others can be resolved along with > >>>>>>> any last call feedback. > >>>>>>> > >>>>>>> *** Please resolve prior to IETF LC *** > >>>>>>> > >>>>>>> =C2=A74: The relaxation of authentication requirements for > >>>>>>> DTLS-SRTP and SDES could use some elaboration on why this > >>>>>>> acceptable. I _think_ the answer is that, since OSRTP > >>>>>>> doesn=E2=80=99t guaranty authentication, there=E2=80=99s no need = for such > >>>>>>> a guaranty from the signaling channel. Is that correct? > >>>>>>> > >>>>>>> OTOH, =C2=A71 says "third mode for security between > >>>>>>> "cleartext=E2=80=9D and "comprehensive protection" that allows > >>>>>>> encryption and authentication to be used if supported=E2=80=A6=E2= =80=9D. > >>>>>>> That suggests that that authentication is sometimes > >>>>>>> provided. Is there a distinction between the > >>>>>>> authenticated case and unauthenticated case that should > >>>>>>> be mentioned somewhere? (For example, is there a need to > >>>>>>> indicate the distinction to the user?) > >>>>>>> > >>>>> > >>>>> $1 should I think say "allows encryption and authenticated > >>>>> media" but I cannot remember why we said the signalling > >>>>> authentication requirements are relaxed this has been in the > >>>>> draft from day 1 and I guess it is consistent with the best > >>>>> effort approach. > >>>>> > >>>>> Anyone else want to comment? > >>>>> > >>>>> > >>>>>>> *** Other Substantive Comments *** > >>>>>>> > >>>>>>> =C2=A72: Please use the new boilerplate from RFC 8174. > >>>>> > >>>>> Will do. > >>>>> > >>>>>>> > >>>>>>> =C2=A73.1: Please clarify that that the offer can contain more > >>>>>>> than one key management attribute. This is mentioned in > >>>>>>> =C2=A73.1, but not actually in the section on generating the > >>>>>>> offer. > >>>>> > >>>>> Will do. > >>>>> > >>>>>>> > >>>>>>> *** Editorial Comments *** > >>>>>>> > >>>>>>> =C2=A73: "As discussed in [RFC7435], this is the > >>>>>>> "comprehensive protection" for media mode.=E2=80=9D s/this/that > >>>>> > >>>>> Thanks > >>>>> > >>>>>>> > >>>>>>> =C2=A73.4: "meaning that the decision to create an OSRTP type > >>>>>>> offer or something else should not be influenced=E2=80=9D That=E2= =80=99s > >>>>>>> referring to the decision to create a _new_ offer, right? > >>>>>>> Not the original offer? > >>>>> > >>>>> Correct. > >>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ Sipbrandy > >>>>>>> mailing list Sipbrandy@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/sipbrandy > >>>>>>> > >>>>>> _______________________________________________ Sipbrandy > >>>>>> mailing list Sipbrandy@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/sipbrandy > >>> > >> > > > > _______________________________________________ Sipbrandy mailing > > list Sipbrandy@ietf.org > > https://www.ietf.org/mailman/listinfo/sipbrandy > > From nobody Mon Apr 8 03:49:57 2019 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75271200B8 for ; Mon, 8 Apr 2019 03:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 kMrWsDT1F7bB for ; Mon, 8 Apr 2019 03:49:53 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E020120019 for ; Mon, 8 Apr 2019 03:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1554720590; x=1557312590; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=PnmjdD5CPcBpTsIflaGCa157zMK37Zp1jNMqso4QszE=; b=G4lfD4ZYGSBx1zGwTFRy+eDsnumZr/9QBi/y8fnaWhRCU6IcOYPz12B9/aEmaiXT Dr3gIl6BB4r/zbbHjy2mRdNLPVr/d7rDDx4zT7TpC/eQxSzp9wq0EIPwJVtfs5CM FcaC3iLVjjKhc71IBfIqWbjFD0Rq/KvoL8wvtFtoFu8=; X-AuditID: c1b4fb25-91c349e000001b0f-fd-5cab274e94b0 Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id ED.B6.06927.E472BAC5; Mon, 8 Apr 2019 12:49:50 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 8 Apr 2019 12:49:47 +0200 Received: from [100.120.6.179] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.186) with Microsoft SMTP Server id 15.1.1713.5 via Frontend Transport; Mon, 8 Apr 2019 12:49:47 +0200 To: Andy Hutton CC: Ben Campbell , "sipbrandy@ietf.org" , "draft-ietf-sipbrandy-osrtp.all@ietf.org" , Alexey Melnikov References: <72C42C63-D5C4-403D-A895-429CB2238AC3@nostrum.com> <741719ee-bbc6-adaf-a036-8fdd655e470f@ericsson.com> From: Gonzalo Camarillo Openpgp: preference=signencrypt Autocrypt: addr=Gonzalo.Camarillo@ericsson.com; prefer-encrypt=mutual; keydata= xsBNBEtSyYUBCADL7itybUN0VVtGQuO81AdviJNSo/BIc6xuVUofHlr/U9CbQcSrRSggvTfa 6n5o9t9zAuwp9pp+hQfSzn4/LrEaV2BmEfAFclSl57IhsXDJecw58JqGZrjahIjgU+rmZKPE RqLzubmI3ltEolLb4kkB9Y8FIQBnE1N3O0wHp7BE8VI5pQX24UkRkEtUptmhwnaehURg9atb 1myxbt1nUDEA5PLJNbPeXxPRJ058OEnPtToRinSCJ7BFtD6PoeUWgOL4kKdRbMyswDikiXnN Ntj1VkDQ6yi7pOb2qkviOzKOf/smqm4ovMxUrET7SzKw4icArL+xQUW3ayJyfSju1o5rABEB AAHNJkdvbnphbG8gQ2FtYXJpbGxvIDxnY2FtYXJpbEBnbWFpbC5jb20+wsCBBBMBAgArAhsj BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAIZAQUCWhwGngUJFGzXmQAKCRDRM1CYcD+HNkjG CACG39D/tNsA5xxSqRtN3JJCTfpj+BWqRckMEpBjBWlOOtb94QY8r9NHRIDwvA5qCVYRqQTI qVyReNw/CkOuaah2rbCdhsng6ZAMzFovXSEnbz+wse4QiKybHvjlJJA9qQiNlne57NVlNvLN LrpZJGmSJlJBBEQRq3Z9Crl2tWFkB6mmoXNnoRej6eVmhFoAo3td5loHo55nqYVZYtAHbXan ggmPI12gUigKf4PuvIISpdokSlkpam02Y61ygtqrlYvNnM+GpbayW2X3ZY5x6bwUwfkRSUCj +xslGaRfJUwr8kUxhVlcLR6qVcjNxWeZf9XKVH86OxEJVUVFsChlDAvHzsBNBEtSyYUBCADB qzP0B7lWge5Hn1648WPWrmUg8r3723XL/zUZe1zyEVsY9VyWhrBmuEy7Xm7wdLt0+BBXWJez 7/wWR9w/63qT+3+W0fe6SDXeZqF+HtYO5QPuu/VYtex0e3TI2w4s53ZM5KQCQF60kTDoK43e 5a6/G2GCKMPpkVKxpIeOiDITiRXq9GV7KHkQpPczqj9ImWp2M9sEIngZRaKILU//TaiWnRGR i6vN/sAvfEuu1fXTwpR6bBdD9wIZgyeSqEgxnioDdyFZYkTFl9G8TuLxNIdpVPzW2M9PKRQs i/kl/Kadsgnd8RtlP7cPoIqLMjmOfGwR8EVbKpmkM1+iKJ+g9F/bABEBAAHCwGUEGAECAA8C GwwFAlocBq4FCRRs16kACgkQ0TNQmHA/hzamwgf/Tnr7/WYnKNmEYvwr/GxhSelVYsBwejkz tCXa4gmVkErgPBEYsUtWAP+jVoYndG74v/3zBPHl4CehE9RnAJ+lpsWjwsn0qPI7sCik3Xqv c44g/RQF9RSI8DckQM0MqLJNazzq4tBi/ZbILWNx2N4LrEzhwoePug3MDn3rCv1Xpr/B60or p1zixtSRKyZo+L7UjttUdJkqxUbC35pBlZlDAL2Dop9He7XwUFofyW1Xvn9xxx0NasnlJX9G 288peTb41bQrs9SqaH1aVLXBTo7S9o+8oB9DLTIIwDQqfxqTWpGIfBhiTm9d7ai9WcFC8jSW zJtc/6luXoGjvUlBzQx0jQ== Message-ID: <2e599cba-8f58-d1e5-3387-28013b26302d@ericsson.com> Date: Mon, 8 Apr 2019 13:49:46 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbG9VNdPfXWMwbrpahYzVhdZXFq3lcli fudpdosb18+xWaxYd4rJgdVj56y77B5Llvxk8jjVbOgxa+cTlgCWKC6blNSczLLUIn27BK6M 8wu+sBWcs6+4c3UHawPjZZMuRk4OCQETiXULzrB1MXJxCAkcZZRY8H4ZM4TzlVHi09aHUM5h RokbZ96wg7QIC7hLXH90iAnEFhHQlng3ZQcrSBGzwFVGiY3H70LN2sgi8WjRe1aQKjYBC4kt t+6zgNj8AvISXQuuMoPYjAL3eCUmPM0HsXkF7CXOPTvOBmKzCKhIbLwIUS8qECux7u4KZoga QYmTM5+AxTkFAiXuPHsNNJ8DaLOmxPpd+iBhZgFxiVtP5jNB2PISzVtng7UKAR26/FkLywRG kVlIJs1C6J6FpHsWku4FjCyrGEWLU4uTctONjPVSizKTi4vz8/TyUks2MQIj6OCW36o7GC+/ cTzEKMDBqMTDu0RsdYwQa2JZcWXuIUYJDmYlEd6dU1fFCPGmJFZWpRblxxeV5qQWH2KU5mBR Euf9IyQYIySQnliSmp2aWpBaBJNl4uCUamBknN7fln+4909E5aInfDIFv3QCgsQeagie/716 k4+z9I6QIoXZMU2RX41iHVmEo6cqOBmlbXQO7T2bcuw6R75azJbTXvbzhQx+vNvbOE1W6ZZg zunvagcV7zU3bng1S0pbaMui159lOhbZt/4ScTxebZD4Yx9j6xv1EinNvZ858+LDf5qaLVZi Kc5INNRiLipOBAB9Mo3ZnAIAAA== Archived-At: Subject: Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-osrtp-07 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 10:49:56 -0000 Hi Ben, could you please look into what Andy ways and confirm whether or not you are happy with the current revision of the draft? Thanks! Cheers, Gonzalo On 08-Apr-19 13:47, Andy Hutton wrote: > I looked at this again and I am not convinced that any further changes > to the draft are needed but if someone wants to suggest text then I > can include it in the draft. > > In the case of SDES the security considerations states that an > encrypted signalling channel must still be used so this draft changes > nothing with respect to intermediaries and the SDES (RFC 4568) > security considerations still apply. > > Regards > Andy > > On Tue, 2 Apr 2019 at 14:56, Gonzalo Camarillo > wrote: >> >> Hi Andy, >> >> Ben's response below indicates that his main substantive comment was not >> addressed in the revision you submitted last week. Could you please look >> into it and get back to Ben? Thanks! >> >>>> With regard to Ben's comment on the relaxing of the authentication >>>> requirement then this is consistent with the Opportunistic >>>> Security RFC 7435 and I added a reference to this as >>>> clarification. >>> >>> If I recall correctly, RFC 7435 does not discuss scenarios with >>> separate signaling and media channels, and how OS applies to each >>> channel. I was looking more for something about the impacts of this >>> “relaxation” specific to these sorts of scenarios with dtls-srtp and >>> sdes, and resulting assurances. >>> >>> For example, dtls-srtp with no authentication does not give you >>> assurances about who you are talking to, but it still allows >>> encryption. SDES without encryption lets an eavesdropper potentially >>> learn the encryption keys, etc. SDES with transport level protection >>> (e.g. SIPS) protects from off-path eavesdroppers, but allows proxies >>> and b2bua’s in the signaling path to learn the encryption keys. >> >> >> Cheers, >> >> Gonzalo >> >> On 02-Apr-19 16:50, Andy Hutton wrote: >>> I believe all Ben's points are addressed in the draft I submitted >>> last week https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-08 >>> >>> Regards Andy >>> >>> On Tue, 2 Apr 2019 at 12:03, Gonzalo Camarillo >>> wrote: >>>> >>>> Hi Andy, authors, >>>> >>>> could you please let Alexey when he should expect a new revision of >>>> this draft that addresses Ben's point below? >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >>>> On 26-Mar-19 18:10, Ben Campbell wrote: >>>>> (+Alexey, who will take over SIPBRANDY when I step down as AD) >>>>> >>>>> Hi, >>>>> >>>>> Thanks for the response. This does not quite address my main >>>>> substantive comment. It does address everything else :-) >>>>> >>>>> Please see comment in line. >>>>> >>>>> Thanks! >>>>> >>>>> Ben. >>>>> >>>>>> On Mar 26, 2019, at 11:58 AM, Andy Hutton >>>>>> wrote: >>>>>> >>>>>> I submitted an update in response to Ben's comments - >>>>>> https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-08 >>>>>> >>>>>> With regard to Ben's comment on the relaxing of the >>>>>> authentication requirement then this is consistent with the >>>>>> Opportunistic Security RFC 7435 and I added a reference to this >>>>>> as clarification. >>>>> >>>>> If I recall correctly, RFC 7435 does not discuss scenarios with >>>>> separate signaling and media channels, and how OS applies to each >>>>> channel. I was looking more for something about the impacts of >>>>> this “relaxation” specific to these sorts of scenarios with >>>>> dtls-srtp and sdes, and resulting assurances. >>>>> >>>>> For example, dtls-srtp with no authentication does not give you >>>>> assurances about who you are talking to, but it still allows >>>>> encryption. SDES without encryption lets an eavesdropper >>>>> potentially learn the encryption keys, etc. SDES with transport >>>>> level protection (e.g. SIPS) protects from off-path >>>>> eavesdroppers, but allows proxies and b2bua’s in the signaling >>>>> path to learn the encryption keys. >>>>> >>>>> >>>>>> >>>>>> Hopefully we can get this to RFC status now. >>>>>> >>>>>> Regards Andy >>>>>> >>>>>> On Mon, 25 Mar 2019 at 22:26, Andy Hutton >>>>>> wrote: >>>>>>> >>>>>>> Sorry about the delay. >>>>>>> >>>>>>> See below. >>>>>>> >>>>>>> I will update the draft. >>>>>>> >>>>>>> Andy >>>>>>> >>>>>>> On Fri, 15 Feb 2019 at 08:46, Gonzalo Camarillo >>>>>>> wrote: >>>>>>>> >>>>>>>> Thanks for the quick review, Ben! >>>>>>>> >>>>>>>> Authors, please address Ben's comments below. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Gonzalo >>>>>>>> >>>>>>>> On 14-Feb-19 22:46, Ben Campbell wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> This is my AD Evaluation of >>>>>>>>> draft-ietf-sipbrandy-osrtp-07. >>>>>>>>> >>>>>>>>> Thank you for a readable and easy to understand >>>>>>>>> document.There is one comment I would like to resolve >>>>>>>>> prior to IETF LC. The others can be resolved along with >>>>>>>>> any last call feedback. >>>>>>>>> >>>>>>>>> *** Please resolve prior to IETF LC *** >>>>>>>>> >>>>>>>>> §4: The relaxation of authentication requirements for >>>>>>>>> DTLS-SRTP and SDES could use some elaboration on why this >>>>>>>>> acceptable. I _think_ the answer is that, since OSRTP >>>>>>>>> doesn’t guaranty authentication, there’s no need for such >>>>>>>>> a guaranty from the signaling channel. Is that correct? >>>>>>>>> >>>>>>>>> OTOH, §1 says "third mode for security between >>>>>>>>> "cleartext” and "comprehensive protection" that allows >>>>>>>>> encryption and authentication to be used if supported…”. >>>>>>>>> That suggests that that authentication is sometimes >>>>>>>>> provided. Is there a distinction between the >>>>>>>>> authenticated case and unauthenticated case that should >>>>>>>>> be mentioned somewhere? (For example, is there a need to >>>>>>>>> indicate the distinction to the user?) >>>>>>>>> >>>>>>> >>>>>>> $1 should I think say "allows encryption and authenticated >>>>>>> media" but I cannot remember why we said the signalling >>>>>>> authentication requirements are relaxed this has been in the >>>>>>> draft from day 1 and I guess it is consistent with the best >>>>>>> effort approach. >>>>>>> >>>>>>> Anyone else want to comment? >>>>>>> >>>>>>> >>>>>>>>> *** Other Substantive Comments *** >>>>>>>>> >>>>>>>>> §2: Please use the new boilerplate from RFC 8174. >>>>>>> >>>>>>> Will do. >>>>>>> >>>>>>>>> >>>>>>>>> §3.1: Please clarify that that the offer can contain more >>>>>>>>> than one key management attribute. This is mentioned in >>>>>>>>> §3.1, but not actually in the section on generating the >>>>>>>>> offer. >>>>>>> >>>>>>> Will do. >>>>>>> >>>>>>>>> >>>>>>>>> *** Editorial Comments *** >>>>>>>>> >>>>>>>>> §3: "As discussed in [RFC7435], this is the >>>>>>>>> "comprehensive protection" for media mode.” s/this/that >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>>>> >>>>>>>>> §3.4: "meaning that the decision to create an OSRTP type >>>>>>>>> offer or something else should not be influenced” That’s >>>>>>>>> referring to the decision to create a _new_ offer, right? >>>>>>>>> Not the original offer? >>>>>>> >>>>>>> Correct. >>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ Sipbrandy >>>>>>>>> mailing list Sipbrandy@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sipbrandy >>>>>>>>> >>>>>>>> _______________________________________________ Sipbrandy >>>>>>>> mailing list Sipbrandy@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sipbrandy >>>>> >>>> >>> >>> _______________________________________________ Sipbrandy mailing >>> list Sipbrandy@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipbrandy >>> > > _______________________________________________ > Sipbrandy mailing list > Sipbrandy@ietf.org > https://www.ietf.org/mailman/listinfo/sipbrandy > From nobody Tue Apr 23 02:33:03 2019 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EF812023C; Tue, 23 Apr 2019 02:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=ericsson.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 oKysTCGA8MdB; Tue, 23 Apr 2019 02:32:58 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150082.outbound.protection.outlook.com [40.107.15.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27EFB12004D; Tue, 23 Apr 2019 02:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HptMC+r+1pdQ0TV/MKVIQltrJp/I1rLsRR/V5fsK2JY=; b=YHvJdNAUGEbfNRvcYDwaNPQcvrUk5dqUbiGotZOd8TNeehtsMDMKoy4f6YSNrZTBoelB06mB4IW53o/d+ShCoqPnA8f8F3KJ5KQh+h1fa0JRPfts9kQHonyRJUdVe8LLzNGu/v5pHuJbCskEMOdFKqXeBGOJyf7IR7KvU7GLCAk= Received: from AM6PR0702MB3688.eurprd07.prod.outlook.com (52.133.24.141) by AM6PR0702MB3590.eurprd07.prod.outlook.com (52.133.24.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.6; Tue, 23 Apr 2019 09:32:54 +0000 Received: from AM6PR0702MB3688.eurprd07.prod.outlook.com ([fe80::b42f:1195:9967:b99f]) by AM6PR0702MB3688.eurprd07.prod.outlook.com ([fe80::b42f:1195:9967:b99f%7]) with mapi id 15.20.1835.010; Tue, 23 Apr 2019 09:32:54 +0000 From: Gonzalo Camarillo To: Andy Hutton CC: Ben Campbell , "sipbrandy@ietf.org" , "draft-ietf-sipbrandy-osrtp.all@ietf.org" , Alexey Melnikov Thread-Topic: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-osrtp-07 Thread-Index: AQHU+beGpGJNJYZf0Uqf4kmSWBC/zg== Date: Tue, 23 Apr 2019 09:32:54 +0000 Message-ID: References: <72C42C63-D5C4-403D-A895-429CB2238AC3@nostrum.com> <741719ee-bbc6-adaf-a036-8fdd655e470f@ericsson.com> <2e599cba-8f58-d1e5-3387-28013b26302d@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gonzalo.camarillo@ericsson.com; x-originating-ip: [185.188.8.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a6a1cec4-1b1a-47c3-ee78-08d6c7ceaa0a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:AM6PR0702MB3590; x-ms-traffictypediagnostic: AM6PR0702MB3590: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0016DEFF96 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(376002)(396003)(366004)(346002)(189003)(199004)(51914003)(3846002)(55016002)(71200400001)(86362001)(71190400001)(2906002)(6116002)(76116006)(9686003)(54906003)(6916009)(76176011)(73956011)(66446008)(66946007)(91956017)(44832011)(66476007)(64756008)(66556008)(6306002)(486006)(229853002)(8936002)(8676002)(476003)(6436002)(53936002)(7696005)(305945005)(81156014)(81166006)(74316002)(7736002)(256004)(14444005)(52536014)(102836004)(66066001)(446003)(478600001)(186003)(14454004)(316002)(93886005)(68736007)(26005)(966005)(4326008)(25786009)(6506007)(99286004)(6246003)(97736004)(53546011)(5660300002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR0702MB3590; H:AM6PR0702MB3688.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: BFdG/T+SWihIUKcgclJXwFbCRsxCI1fVzGA5rSmlw2cfyXQPpU7358JBIu9+05syV2bNDCvk851KDB+zU+79wZGvwNUzGegmq0l5K2Tb+Y80aI4N6diTPxDJyHjgfmV6Xl3Y55x9YGrwpxM1WzeL7rFJGEoZ82SNC6wpuM5JckxzI8EAq/h/IFoBfHRNwI+cmBOkaQIxsjiXHa/JvO2PYSAn29D0dcxmIfoydIq4MmXnbjgXnDsLfPr+WXprrVnTAZsRNaKWlmRBHbzDbzSbqVm5MHe5ofJU9ixfyBXN0gbpV6BUBSXVjZNX14tIUQG6cy8PmmMGa4a1TaOzIPsyk9aTiFFU1E+WnWbJvrueUmsUgKnAuJlyygzepNoj6dRuMIR+GmuppO81o08ZHO5vi3lGFOP88aAMksxFWBQMDbo= Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a6a1cec4-1b1a-47c3-ee78-08d6c7ceaa0a X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2019 09:32:54.8607 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR0702MB3590 Archived-At: Subject: Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-osrtp-07 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 09:33:01 -0000 Hi Ben,=0A= =0A= when do you think you will be able to look into this? Thanks!=0A= =0A= Cheers,=0A= =0A= Gonzalo=0A= =0A= On 08-Apr-19 13:49, Gonzalo Camarillo wrote:=0A= > Hi Ben,=0A= > =0A= > could you please look into what Andy ways and confirm whether or not you= =0A= > are happy with the current revision of the draft? Thanks!=0A= > =0A= > Cheers,=0A= > =0A= > Gonzalo=0A= > =0A= > On 08-Apr-19 13:47, Andy Hutton wrote:=0A= >> I looked at this again and I am not convinced that any further changes= =0A= >> to the draft are needed but if someone wants to suggest text then I=0A= >> can include it in the draft.=0A= >>=0A= >> In the case of SDES the security considerations states that an=0A= >> encrypted signalling channel must still be used so this draft changes=0A= >> nothing with respect to intermediaries and the SDES (RFC 4568)=0A= >> security considerations still apply.=0A= >>=0A= >> Regards=0A= >> Andy=0A= >>=0A= >> On Tue, 2 Apr 2019 at 14:56, Gonzalo Camarillo=0A= >> wrote:=0A= >>>=0A= >>> Hi Andy,=0A= >>>=0A= >>> Ben's response below indicates that his main substantive comment was no= t=0A= >>> addressed in the revision you submitted last week. Could you please loo= k=0A= >>> into it and get back to Ben? Thanks!=0A= >>>=0A= >>>>> With regard to Ben's comment on the relaxing of the authentication=0A= >>>>> requirement then this is consistent with the Opportunistic=0A= >>>>> Security RFC 7435 and I added a reference to this as=0A= >>>>> clarification.=0A= >>>>=0A= >>>> If I recall correctly, RFC 7435 does not discuss scenarios with=0A= >>>> separate signaling and media channels, and how OS applies to each=0A= >>>> channel. I was looking more for something about the impacts of this=0A= >>>> =93relaxation=94 specific to these sorts of scenarios with dtls-srtp a= nd=0A= >>>> sdes, and resulting assurances.=0A= >>>>=0A= >>>> For example, dtls-srtp with no authentication does not give you=0A= >>>> assurances about who you are talking to, but it still allows=0A= >>>> encryption. SDES without encryption lets an eavesdropper potentially= =0A= >>>> learn the encryption keys, etc. SDES with transport level protection= =0A= >>>> (e.g. SIPS) protects from off-path eavesdroppers, but allows proxies= =0A= >>>> and b2bua=92s in the signaling path to learn the encryption keys.=0A= >>>=0A= >>>=0A= >>> Cheers,=0A= >>>=0A= >>> Gonzalo=0A= >>>=0A= >>> On 02-Apr-19 16:50, Andy Hutton wrote:=0A= >>>> I believe all Ben's points are addressed in the draft I submitted=0A= >>>> last week https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-08=0A= >>>>=0A= >>>> Regards Andy=0A= >>>>=0A= >>>> On Tue, 2 Apr 2019 at 12:03, Gonzalo Camarillo=0A= >>>> wrote:=0A= >>>>>=0A= >>>>> Hi Andy, authors,=0A= >>>>>=0A= >>>>> could you please let Alexey when he should expect a new revision of= =0A= >>>>> this draft that addresses Ben's point below?=0A= >>>>>=0A= >>>>> Cheers,=0A= >>>>>=0A= >>>>> Gonzalo=0A= >>>>>=0A= >>>>> On 26-Mar-19 18:10, Ben Campbell wrote:=0A= >>>>>> (+Alexey, who will take over SIPBRANDY when I step down as AD)=0A= >>>>>>=0A= >>>>>> Hi,=0A= >>>>>>=0A= >>>>>> Thanks for the response. This does not quite address my main=0A= >>>>>> substantive comment. It does address everything else :-)=0A= >>>>>>=0A= >>>>>> Please see comment in line.=0A= >>>>>>=0A= >>>>>> Thanks!=0A= >>>>>>=0A= >>>>>> Ben.=0A= >>>>>>=0A= >>>>>>> On Mar 26, 2019, at 11:58 AM, Andy Hutton=0A= >>>>>>> wrote:=0A= >>>>>>>=0A= >>>>>>> I submitted an update in response to Ben's comments -=0A= >>>>>>> https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-08=0A= >>>>>>>=0A= >>>>>>> With regard to Ben's comment on the relaxing of the=0A= >>>>>>> authentication requirement then this is consistent with the=0A= >>>>>>> Opportunistic Security RFC 7435 and I added a reference to this=0A= >>>>>>> as clarification.=0A= >>>>>>=0A= >>>>>> If I recall correctly, RFC 7435 does not discuss scenarios with=0A= >>>>>> separate signaling and media channels, and how OS applies to each=0A= >>>>>> channel. I was looking more for something about the impacts of=0A= >>>>>> this =93relaxation=94 specific to these sorts of scenarios with=0A= >>>>>> dtls-srtp and sdes, and resulting assurances.=0A= >>>>>>=0A= >>>>>> For example, dtls-srtp with no authentication does not give you=0A= >>>>>> assurances about who you are talking to, but it still allows=0A= >>>>>> encryption. SDES without encryption lets an eavesdropper=0A= >>>>>> potentially learn the encryption keys, etc. SDES with transport=0A= >>>>>> level protection (e.g. SIPS) protects from off-path=0A= >>>>>> eavesdroppers, but allows proxies and b2bua=92s in the signaling=0A= >>>>>> path to learn the encryption keys.=0A= >>>>>>=0A= >>>>>>=0A= >>>>>>>=0A= >>>>>>> Hopefully we can get this to RFC status now.=0A= >>>>>>>=0A= >>>>>>> Regards Andy=0A= >>>>>>>=0A= >>>>>>> On Mon, 25 Mar 2019 at 22:26, Andy Hutton=0A= >>>>>>> wrote:=0A= >>>>>>>>=0A= >>>>>>>> Sorry about the delay.=0A= >>>>>>>>=0A= >>>>>>>> See below.=0A= >>>>>>>>=0A= >>>>>>>> I will update the draft.=0A= >>>>>>>>=0A= >>>>>>>> Andy=0A= >>>>>>>>=0A= >>>>>>>> On Fri, 15 Feb 2019 at 08:46, Gonzalo Camarillo=0A= >>>>>>>> wrote:=0A= >>>>>>>>>=0A= >>>>>>>>> Thanks for the quick review, Ben!=0A= >>>>>>>>>=0A= >>>>>>>>> Authors, please address Ben's comments below.=0A= >>>>>>>>>=0A= >>>>>>>>> Cheers,=0A= >>>>>>>>>=0A= >>>>>>>>> Gonzalo=0A= >>>>>>>>>=0A= >>>>>>>>> On 14-Feb-19 22:46, Ben Campbell wrote:=0A= >>>>>>>>>> Hi,=0A= >>>>>>>>>>=0A= >>>>>>>>>> This is my AD Evaluation of=0A= >>>>>>>>>> draft-ietf-sipbrandy-osrtp-07.=0A= >>>>>>>>>>=0A= >>>>>>>>>> Thank you for a readable and easy to understand=0A= >>>>>>>>>> document.There is one comment I would like to resolve=0A= >>>>>>>>>> prior to IETF LC. The others can be resolved along with=0A= >>>>>>>>>> any last call feedback.=0A= >>>>>>>>>>=0A= >>>>>>>>>> *** Please resolve prior to IETF LC ***=0A= >>>>>>>>>>=0A= >>>>>>>>>> =A74: The relaxation of authentication requirements for=0A= >>>>>>>>>> DTLS-SRTP and SDES could use some elaboration on why this=0A= >>>>>>>>>> acceptable. I _think_ the answer is that, since OSRTP=0A= >>>>>>>>>> doesn=92t guaranty authentication, there=92s no need for such=0A= >>>>>>>>>> a guaranty from the signaling channel. Is that correct?=0A= >>>>>>>>>>=0A= >>>>>>>>>> OTOH, =A71 says "third mode for security between=0A= >>>>>>>>>> "cleartext=94 and "comprehensive protection" that allows=0A= >>>>>>>>>> encryption and authentication to be used if supported=85=94.=0A= >>>>>>>>>> That suggests that that authentication is sometimes=0A= >>>>>>>>>> provided. Is there a distinction between the=0A= >>>>>>>>>> authenticated case and unauthenticated case that should=0A= >>>>>>>>>> be mentioned somewhere? (For example, is there a need to=0A= >>>>>>>>>> indicate the distinction to the user?)=0A= >>>>>>>>>>=0A= >>>>>>>>=0A= >>>>>>>> $1 should I think say "allows encryption and authenticated=0A= >>>>>>>> media" but I cannot remember why we said the signalling=0A= >>>>>>>> authentication requirements are relaxed this has been in the=0A= >>>>>>>> draft from day 1 and I guess it is consistent with the best=0A= >>>>>>>> effort approach.=0A= >>>>>>>>=0A= >>>>>>>> Anyone else want to comment?=0A= >>>>>>>>=0A= >>>>>>>>=0A= >>>>>>>>>> *** Other Substantive Comments ***=0A= >>>>>>>>>>=0A= >>>>>>>>>> =A72: Please use the new boilerplate from RFC 8174.=0A= >>>>>>>>=0A= >>>>>>>> Will do.=0A= >>>>>>>>=0A= >>>>>>>>>>=0A= >>>>>>>>>> =A73.1: Please clarify that that the offer can contain more=0A= >>>>>>>>>> than one key management attribute. This is mentioned in=0A= >>>>>>>>>> =A73.1, but not actually in the section on generating the=0A= >>>>>>>>>> offer.=0A= >>>>>>>>=0A= >>>>>>>> Will do.=0A= >>>>>>>>=0A= >>>>>>>>>>=0A= >>>>>>>>>> *** Editorial Comments ***=0A= >>>>>>>>>>=0A= >>>>>>>>>> =A73: "As discussed in [RFC7435], this is the=0A= >>>>>>>>>> "comprehensive protection" for media mode.=94 s/this/that=0A= >>>>>>>>=0A= >>>>>>>> Thanks=0A= >>>>>>>>=0A= >>>>>>>>>>=0A= >>>>>>>>>> =A73.4: "meaning that the decision to create an OSRTP type=0A= >>>>>>>>>> offer or something else should not be influenced=94 That=92s=0A= >>>>>>>>>> referring to the decision to create a _new_ offer, right?=0A= >>>>>>>>>> Not the original offer?=0A= >>>>>>>>=0A= >>>>>>>> Correct.=0A= >>>>>>>>=0A= >>>>>>>>>>=0A= >>>>>>>>>>=0A= >>>>>>>>>>=0A= >>>>>>>>>> _______________________________________________ Sipbrandy=0A= >>>>>>>>>> mailing list Sipbrandy@ietf.org=0A= >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipbrandy=0A= >>>>>>>>>>=0A= >>>>>>>>> _______________________________________________ Sipbrandy=0A= >>>>>>>>> mailing list Sipbrandy@ietf.org=0A= >>>>>>>>> https://www.ietf.org/mailman/listinfo/sipbrandy=0A= >>>>>>=0A= >>>>>=0A= >>>>=0A= >>>> _______________________________________________ Sipbrandy mailing=0A= >>>> list Sipbrandy@ietf.org=0A= >>>> https://www.ietf.org/mailman/listinfo/sipbrandy=0A= >>>>=0A= >>=0A= >> _______________________________________________=0A= >> Sipbrandy mailing list=0A= >> Sipbrandy@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/sipbrandy=0A= >>=0A= > =0A= From nobody Tue Apr 23 13:44:45 2019 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21DA120467; Tue, 23 Apr 2019 13:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 jK8wOvlnUfZ2; Tue, 23 Apr 2019 13:44:42 -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 5007D120388; Tue, 23 Apr 2019 13:44:42 -0700 (PDT) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x3NKiXRT063620 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 Apr 2019 15:44:34 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1556052275; bh=IrjWyBBt89UfCRdl9cNvMuz5jBow9Y3JOLTieahnf0M=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Q9VmAvqEoiPgOEeqqOviN11X9/9ncyUV2S19HI9PcGplVwAYUg/R4FzrFqkx9pbXW i9cBRqrXN+RuwptV83Gqh6cdib9za9zl9gTLrjToA6TNAKy6OzbCP6mpvFKmHkm8dK elGU9K5teODz1ByDZ2c8XKMun6ilW3N/m5Sr8Hh0= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Message-Id: <7B93A5B9-553C-46BA-ACE7-D1BEE10B5841@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_E928AEA4-6F5A-42E0-B679-52316968BC4D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Tue, 23 Apr 2019 15:44:27 -0500 In-Reply-To: <2e599cba-8f58-d1e5-3387-28013b26302d@ericsson.com> Cc: Andy Hutton , "sipbrandy@ietf.org" , "draft-ietf-sipbrandy-osrtp.all@ietf.org" , Alexey Melnikov To: Gonzalo Camarillo References: <72C42C63-D5C4-403D-A895-429CB2238AC3@nostrum.com> <741719ee-bbc6-adaf-a036-8fdd655e470f@ericsson.com> <2e599cba-8f58-d1e5-3387-28013b26302d@ericsson.com> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-osrtp-07 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 20:44:44 -0000 --Apple-Mail=_E928AEA4-6F5A-42E0-B679-52316968BC4D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I will respond separately to Andy=E2=80=99s email. But please keep in = mind I am no longer the responsible AD, and it=E2=80=99s up to Alexey to = decide how to move forward. Thanks! Ben. > On Apr 8, 2019, at 5:49 AM, Gonzalo Camarillo = wrote: >=20 > Hi Ben, >=20 > could you please look into what Andy ways and confirm whether or not = you > are happy with the current revision of the draft? Thanks! >=20 > Cheers, >=20 > Gonzalo >=20 > On 08-Apr-19 13:47, Andy Hutton wrote: >> I looked at this again and I am not convinced that any further = changes >> to the draft are needed but if someone wants to suggest text then I >> can include it in the draft. >>=20 >> In the case of SDES the security considerations states that an >> encrypted signalling channel must still be used so this draft changes >> nothing with respect to intermediaries and the SDES (RFC 4568) >> security considerations still apply. >>=20 >> Regards >> Andy >>=20 >> On Tue, 2 Apr 2019 at 14:56, Gonzalo Camarillo >> wrote: >>>=20 >>> Hi Andy, >>>=20 >>> Ben's response below indicates that his main substantive comment was = not >>> addressed in the revision you submitted last week. Could you please = look >>> into it and get back to Ben? Thanks! >>>=20 >>>>> With regard to Ben's comment on the relaxing of the authentication >>>>> requirement then this is consistent with the Opportunistic >>>>> Security RFC 7435 and I added a reference to this as >>>>> clarification. >>>>=20 >>>> If I recall correctly, RFC 7435 does not discuss scenarios with >>>> separate signaling and media channels, and how OS applies to each >>>> channel. I was looking more for something about the impacts of this >>>> =E2=80=9Crelaxation=E2=80=9D specific to these sorts of scenarios = with dtls-srtp and >>>> sdes, and resulting assurances. >>>>=20 >>>> For example, dtls-srtp with no authentication does not give you >>>> assurances about who you are talking to, but it still allows >>>> encryption. SDES without encryption lets an eavesdropper = potentially >>>> learn the encryption keys, etc. SDES with transport level = protection >>>> (e.g. SIPS) protects from off-path eavesdroppers, but allows = proxies >>>> and b2bua=E2=80=99s in the signaling path to learn the encryption = keys. >>>=20 >>>=20 >>> Cheers, >>>=20 >>> Gonzalo >>>=20 >>> On 02-Apr-19 16:50, Andy Hutton wrote: >>>> I believe all Ben's points are addressed in the draft I submitted >>>> last week https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-08 >>>>=20 >>>> Regards Andy >>>>=20 >>>> On Tue, 2 Apr 2019 at 12:03, Gonzalo Camarillo >>>> wrote: >>>>>=20 >>>>> Hi Andy, authors, >>>>>=20 >>>>> could you please let Alexey when he should expect a new revision = of >>>>> this draft that addresses Ben's point below? >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Gonzalo >>>>>=20 >>>>> On 26-Mar-19 18:10, Ben Campbell wrote: >>>>>> (+Alexey, who will take over SIPBRANDY when I step down as AD) >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> Thanks for the response. This does not quite address my main >>>>>> substantive comment. It does address everything else :-) >>>>>>=20 >>>>>> Please see comment in line. >>>>>>=20 >>>>>> Thanks! >>>>>>=20 >>>>>> Ben. >>>>>>=20 >>>>>>> On Mar 26, 2019, at 11:58 AM, Andy Hutton >>>>>>> wrote: >>>>>>>=20 >>>>>>> I submitted an update in response to Ben's comments - >>>>>>> https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-08 >>>>>>>=20 >>>>>>> With regard to Ben's comment on the relaxing of the >>>>>>> authentication requirement then this is consistent with the >>>>>>> Opportunistic Security RFC 7435 and I added a reference to this >>>>>>> as clarification. >>>>>>=20 >>>>>> If I recall correctly, RFC 7435 does not discuss scenarios with >>>>>> separate signaling and media channels, and how OS applies to each >>>>>> channel. I was looking more for something about the impacts of >>>>>> this =E2=80=9Crelaxation=E2=80=9D specific to these sorts of = scenarios with >>>>>> dtls-srtp and sdes, and resulting assurances. >>>>>>=20 >>>>>> For example, dtls-srtp with no authentication does not give you >>>>>> assurances about who you are talking to, but it still allows >>>>>> encryption. SDES without encryption lets an eavesdropper >>>>>> potentially learn the encryption keys, etc. SDES with transport >>>>>> level protection (e.g. SIPS) protects from off-path >>>>>> eavesdroppers, but allows proxies and b2bua=E2=80=99s in the = signaling >>>>>> path to learn the encryption keys. >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Hopefully we can get this to RFC status now. >>>>>>>=20 >>>>>>> Regards Andy >>>>>>>=20 >>>>>>> On Mon, 25 Mar 2019 at 22:26, Andy Hutton >>>>>>> wrote: >>>>>>>>=20 >>>>>>>> Sorry about the delay. >>>>>>>>=20 >>>>>>>> See below. >>>>>>>>=20 >>>>>>>> I will update the draft. >>>>>>>>=20 >>>>>>>> Andy >>>>>>>>=20 >>>>>>>> On Fri, 15 Feb 2019 at 08:46, Gonzalo Camarillo >>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Thanks for the quick review, Ben! >>>>>>>>>=20 >>>>>>>>> Authors, please address Ben's comments below. >>>>>>>>>=20 >>>>>>>>> Cheers, >>>>>>>>>=20 >>>>>>>>> Gonzalo >>>>>>>>>=20 >>>>>>>>> On 14-Feb-19 22:46, Ben Campbell wrote: >>>>>>>>>> Hi, >>>>>>>>>>=20 >>>>>>>>>> This is my AD Evaluation of >>>>>>>>>> draft-ietf-sipbrandy-osrtp-07. >>>>>>>>>>=20 >>>>>>>>>> Thank you for a readable and easy to understand >>>>>>>>>> document.There is one comment I would like to resolve >>>>>>>>>> prior to IETF LC. The others can be resolved along with >>>>>>>>>> any last call feedback. >>>>>>>>>>=20 >>>>>>>>>> *** Please resolve prior to IETF LC *** >>>>>>>>>>=20 >>>>>>>>>> =C2=A74: The relaxation of authentication requirements for >>>>>>>>>> DTLS-SRTP and SDES could use some elaboration on why this >>>>>>>>>> acceptable. I _think_ the answer is that, since OSRTP >>>>>>>>>> doesn=E2=80=99t guaranty authentication, there=E2=80=99s no = need for such >>>>>>>>>> a guaranty from the signaling channel. Is that correct? >>>>>>>>>>=20 >>>>>>>>>> OTOH, =C2=A71 says "third mode for security between >>>>>>>>>> "cleartext=E2=80=9D and "comprehensive protection" that = allows >>>>>>>>>> encryption and authentication to be used if supported=E2=80=A6=E2= =80=9D. >>>>>>>>>> That suggests that that authentication is sometimes >>>>>>>>>> provided. Is there a distinction between the >>>>>>>>>> authenticated case and unauthenticated case that should >>>>>>>>>> be mentioned somewhere? (For example, is there a need to >>>>>>>>>> indicate the distinction to the user?) >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> $1 should I think say "allows encryption and authenticated >>>>>>>> media" but I cannot remember why we said the signalling >>>>>>>> authentication requirements are relaxed this has been in the >>>>>>>> draft from day 1 and I guess it is consistent with the best >>>>>>>> effort approach. >>>>>>>>=20 >>>>>>>> Anyone else want to comment? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> *** Other Substantive Comments *** >>>>>>>>>>=20 >>>>>>>>>> =C2=A72: Please use the new boilerplate from RFC 8174. >>>>>>>>=20 >>>>>>>> Will do. >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> =C2=A73.1: Please clarify that that the offer can contain = more >>>>>>>>>> than one key management attribute. This is mentioned in >>>>>>>>>> =C2=A73.1, but not actually in the section on generating the >>>>>>>>>> offer. >>>>>>>>=20 >>>>>>>> Will do. >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> *** Editorial Comments *** >>>>>>>>>>=20 >>>>>>>>>> =C2=A73: "As discussed in [RFC7435], this is the >>>>>>>>>> "comprehensive protection" for media mode.=E2=80=9D = s/this/that >>>>>>>>=20 >>>>>>>> Thanks >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> =C2=A73.4: "meaning that the decision to create an OSRTP type >>>>>>>>>> offer or something else should not be influenced=E2=80=9D = That=E2=80=99s >>>>>>>>>> referring to the decision to create a _new_ offer, right? >>>>>>>>>> Not the original offer? >>>>>>>>=20 >>>>>>>> Correct. >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ Sipbrandy >>>>>>>>>> mailing list Sipbrandy@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipbrandy >>>>>>>>>>=20 >>>>>>>>> _______________________________________________ Sipbrandy >>>>>>>>> mailing list Sipbrandy@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sipbrandy >>>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ Sipbrandy mailing >>>> list Sipbrandy@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipbrandy >>>>=20 >>=20 >> _______________________________________________ >> Sipbrandy mailing list >> Sipbrandy@ietf.org >> https://www.ietf.org/mailman/listinfo/sipbrandy >>=20 --Apple-Mail=_E928AEA4-6F5A-42E0-B679-52316968BC4D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAly/eSsACgkQgFZKbJXz 1A1X9Q/+Iw0x3wx/n2UWlAj0OuKJcUSsL8T8c6e/aL1hMyJGQdfvzze9pEm9Lfm/ QGSx3cajS1rn2XRDanaUeuVzpELJnAQN04lz63FrN62QPA9JlaOYpnrdW1BHNioe ti5QzTgpBa8e0PrnUHW/LQN/JHkEzOsyIfhSF2JGFIW7Yun/1wbt6uX0pY8K139h VF5fXBsrji+XCi5PmxvVPTSQPk1rF1bZjwiPpyP2Vp5X0viCChdzG7qUgwsrY+dv wSwnpgnYrEWrhYqn3JvvzdAeUUpFRugNRRGDtPGv0Zw6nyZFQOd1bwgpnAN84gu7 kLFN2/Mi2XqbQ6Q3ia/S1S/RVAPM9m04Zy1tCyaAES05SKPy3XKM/gFNDcCRHmXq FckZxvZjyvRF76/unCjVmv/FGpmv9teE4kg/A7Xfq3YXMsO4iQFgIniFLVhfHO3o 1BCbf+SLonl5Uq8Rj03A0DP/7rrBAP+o7s5r0tok7uV9kCAc1b3VPzWXnLIQ1zHT q1UfJZJpLG5s04zVXfcyJSupOCh9K33dC2QaXp23G2em/qJpbQYaiJbcS6gcrrQD vLb+msKcI4dNzc2T09ztoj+7+Y/Ysn4I0z8ovDtAYKr8fhgiN7U13wMfjKH8pzCJ o5txbkL+epBUfP55Nmesk6lzZjlCS5gU00mvK8FaDE70jTP7FX4= =iWmB -----END PGP SIGNATURE----- --Apple-Mail=_E928AEA4-6F5A-42E0-B679-52316968BC4D-- From nobody Tue Apr 23 14:25:47 2019 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B380120399; Tue, 23 Apr 2019 14:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 c3br1ZGjXeXC; Tue, 23 Apr 2019 14:25:44 -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 909F7120391; Tue, 23 Apr 2019 14:25:44 -0700 (PDT) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x3NLPZEh070217 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 Apr 2019 16:25:36 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1556054738; bh=gsa9U+WnF0m34y2Suf8kYblTBoFa6MxhFW2ELLr75aU=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Dd8EL9kli3PhvojHqfdYlWefPHlkh4Ro5TpHTTi2Mz01DA/ksa0O5TQD95ols6QXo 19MvYKZmRiR3MNpobDRAvD6Z7mK86hsf5aYLub8DuWaTK7QeQXkxHkOYUx84o2aNXD RhlUjvwFMP+GbCq9t9TUZxYVPmtx+Vxlwoa7uav0= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D838564B-C27A-492D-992D-4EB3816903C1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Tue, 23 Apr 2019 16:25:29 -0500 In-Reply-To: Cc: Gonzalo Camarillo , "sipbrandy@ietf.org" , "draft-ietf-sipbrandy-osrtp.all@ietf.org" , ART ADs To: Andy Hutton References: <72C42C63-D5C4-403D-A895-429CB2238AC3@nostrum.com> <741719ee-bbc6-adaf-a036-8fdd655e470f@ericsson.com> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-osrtp-07 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 21:25:46 -0000 --Apple-Mail=_D838564B-C27A-492D-992D-4EB3816903C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 (Please keep in mind I am no longer an AD; at this point my concern = should be treated like last call feedback.) The issue with SDES is that, while SDES says messages with = =E2=80=9Ca=3Dcrypto=E2=80=9D SHOULD be protected end-to-end, and that = hop-by-hop things such as TLS and IPSec SHOULD NOT be used across with = intermediaries, in practice that SHOULD and SHOULD NOT are routinely = ignored. I don=E2=80=99t think this requires a huge change. I propose adding a = paragraph to the effect of the following before the current last = paragraph in section 4: =E2=80=9CWhile OSRTP does not require authentication of the = key-agreement mechanism, it does need them to avoid exposing SRTP keys to eavesdroppers, since this could enable passive attacks = against SRTP. Section 8.3 of [RFC4568] requires that any messages that = contain SRTP keys be encrypted, and further says that encryption = =E2=80=9CSHOULD=E2=80=9D provide end-to-end confidentiality protection = if intermediaries that could inspect the SDP message are present. At the = time of this writing, that =E2=80=9CSHOULD=E2=80=9D is commonly ignored. = Therefore, if OSRTP is used with Security Descriptions, any such = intermediaries (e.g., SIP proxies) must be assumed to have access to the = SRTP keys.=E2=80=9D Thanks! Ben. > On Apr 8, 2019, at 5:47 AM, Andy Hutton = wrote: >=20 > I looked at this again and I am not convinced that any further changes > to the draft are needed but if someone wants to suggest text then I > can include it in the draft. >=20 > In the case of SDES the security considerations states that an > encrypted signalling channel must still be used so this draft changes > nothing with respect to intermediaries and the SDES (RFC 4568) > security considerations still apply. >=20 > Regards > Andy >=20 > On Tue, 2 Apr 2019 at 14:56, Gonzalo Camarillo > wrote: >>=20 >> Hi Andy, >>=20 >> Ben's response below indicates that his main substantive comment was = not >> addressed in the revision you submitted last week. Could you please = look >> into it and get back to Ben? Thanks! >>=20 >>>> With regard to Ben's comment on the relaxing of the authentication >>>> requirement then this is consistent with the Opportunistic >>>> Security RFC 7435 and I added a reference to this as >>>> clarification. >>>=20 >>> If I recall correctly, RFC 7435 does not discuss scenarios with >>> separate signaling and media channels, and how OS applies to each >>> channel. I was looking more for something about the impacts of this >>> =E2=80=9Crelaxation=E2=80=9D specific to these sorts of scenarios = with dtls-srtp and >>> sdes, and resulting assurances. >>>=20 >>> For example, dtls-srtp with no authentication does not give you >>> assurances about who you are talking to, but it still allows >>> encryption. SDES without encryption lets an eavesdropper potentially >>> learn the encryption keys, etc. SDES with transport level protection >>> (e.g. SIPS) protects from off-path eavesdroppers, but allows proxies >>> and b2bua=E2=80=99s in the signaling path to learn the encryption = keys. >>=20 >>=20 >> Cheers, >>=20 >> Gonzalo >>=20 >> On 02-Apr-19 16:50, Andy Hutton wrote: >>> I believe all Ben's points are addressed in the draft I submitted >>> last week https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-08 >>>=20 >>> Regards Andy >>>=20 >>> On Tue, 2 Apr 2019 at 12:03, Gonzalo Camarillo >>> wrote: >>>>=20 >>>> Hi Andy, authors, >>>>=20 >>>> could you please let Alexey when he should expect a new revision of >>>> this draft that addresses Ben's point below? >>>>=20 >>>> Cheers, >>>>=20 >>>> Gonzalo >>>>=20 >>>> On 26-Mar-19 18:10, Ben Campbell wrote: >>>>> (+Alexey, who will take over SIPBRANDY when I step down as AD) >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> Thanks for the response. This does not quite address my main >>>>> substantive comment. It does address everything else :-) >>>>>=20 >>>>> Please see comment in line. >>>>>=20 >>>>> Thanks! >>>>>=20 >>>>> Ben. >>>>>=20 >>>>>> On Mar 26, 2019, at 11:58 AM, Andy Hutton >>>>>> wrote: >>>>>>=20 >>>>>> I submitted an update in response to Ben's comments - >>>>>> https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-08 >>>>>>=20 >>>>>> With regard to Ben's comment on the relaxing of the >>>>>> authentication requirement then this is consistent with the >>>>>> Opportunistic Security RFC 7435 and I added a reference to this >>>>>> as clarification. >>>>>=20 >>>>> If I recall correctly, RFC 7435 does not discuss scenarios with >>>>> separate signaling and media channels, and how OS applies to each >>>>> channel. I was looking more for something about the impacts of >>>>> this =E2=80=9Crelaxation=E2=80=9D specific to these sorts of = scenarios with >>>>> dtls-srtp and sdes, and resulting assurances. >>>>>=20 >>>>> For example, dtls-srtp with no authentication does not give you >>>>> assurances about who you are talking to, but it still allows >>>>> encryption. SDES without encryption lets an eavesdropper >>>>> potentially learn the encryption keys, etc. SDES with transport >>>>> level protection (e.g. SIPS) protects from off-path >>>>> eavesdroppers, but allows proxies and b2bua=E2=80=99s in the = signaling >>>>> path to learn the encryption keys. >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Hopefully we can get this to RFC status now. >>>>>>=20 >>>>>> Regards Andy >>>>>>=20 >>>>>> On Mon, 25 Mar 2019 at 22:26, Andy Hutton >>>>>> wrote: >>>>>>>=20 >>>>>>> Sorry about the delay. >>>>>>>=20 >>>>>>> See below. >>>>>>>=20 >>>>>>> I will update the draft. >>>>>>>=20 >>>>>>> Andy >>>>>>>=20 >>>>>>> On Fri, 15 Feb 2019 at 08:46, Gonzalo Camarillo >>>>>>> wrote: >>>>>>>>=20 >>>>>>>> Thanks for the quick review, Ben! >>>>>>>>=20 >>>>>>>> Authors, please address Ben's comments below. >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>>=20 >>>>>>>> Gonzalo >>>>>>>>=20 >>>>>>>> On 14-Feb-19 22:46, Ben Campbell wrote: >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>> This is my AD Evaluation of >>>>>>>>> draft-ietf-sipbrandy-osrtp-07. >>>>>>>>>=20 >>>>>>>>> Thank you for a readable and easy to understand >>>>>>>>> document.There is one comment I would like to resolve >>>>>>>>> prior to IETF LC. The others can be resolved along with >>>>>>>>> any last call feedback. >>>>>>>>>=20 >>>>>>>>> *** Please resolve prior to IETF LC *** >>>>>>>>>=20 >>>>>>>>> =C2=A74: The relaxation of authentication requirements for >>>>>>>>> DTLS-SRTP and SDES could use some elaboration on why this >>>>>>>>> acceptable. I _think_ the answer is that, since OSRTP >>>>>>>>> doesn=E2=80=99t guaranty authentication, there=E2=80=99s no = need for such >>>>>>>>> a guaranty from the signaling channel. Is that correct? >>>>>>>>>=20 >>>>>>>>> OTOH, =C2=A71 says "third mode for security between >>>>>>>>> "cleartext=E2=80=9D and "comprehensive protection" that allows >>>>>>>>> encryption and authentication to be used if supported=E2=80=A6=E2= =80=9D. >>>>>>>>> That suggests that that authentication is sometimes >>>>>>>>> provided. Is there a distinction between the >>>>>>>>> authenticated case and unauthenticated case that should >>>>>>>>> be mentioned somewhere? (For example, is there a need to >>>>>>>>> indicate the distinction to the user?) >>>>>>>>>=20 >>>>>>>=20 >>>>>>> $1 should I think say "allows encryption and authenticated >>>>>>> media" but I cannot remember why we said the signalling >>>>>>> authentication requirements are relaxed this has been in the >>>>>>> draft from day 1 and I guess it is consistent with the best >>>>>>> effort approach. >>>>>>>=20 >>>>>>> Anyone else want to comment? >>>>>>>=20 >>>>>>>=20 >>>>>>>>> *** Other Substantive Comments *** >>>>>>>>>=20 >>>>>>>>> =C2=A72: Please use the new boilerplate from RFC 8174. >>>>>>>=20 >>>>>>> Will do. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> =C2=A73.1: Please clarify that that the offer can contain more >>>>>>>>> than one key management attribute. This is mentioned in >>>>>>>>> =C2=A73.1, but not actually in the section on generating the >>>>>>>>> offer. >>>>>>>=20 >>>>>>> Will do. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> *** Editorial Comments *** >>>>>>>>>=20 >>>>>>>>> =C2=A73: "As discussed in [RFC7435], this is the >>>>>>>>> "comprehensive protection" for media mode.=E2=80=9D = s/this/that >>>>>>>=20 >>>>>>> Thanks >>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> =C2=A73.4: "meaning that the decision to create an OSRTP type >>>>>>>>> offer or something else should not be influenced=E2=80=9D = That=E2=80=99s >>>>>>>>> referring to the decision to create a _new_ offer, right? >>>>>>>>> Not the original offer? >>>>>>>=20 >>>>>>> Correct. >>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ Sipbrandy >>>>>>>>> mailing list Sipbrandy@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sipbrandy >>>>>>>>>=20 >>>>>>>> _______________________________________________ Sipbrandy >>>>>>>> mailing list Sipbrandy@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sipbrandy >>>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ Sipbrandy mailing >>> list Sipbrandy@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipbrandy >>>=20 --Apple-Mail=_D838564B-C27A-492D-992D-4EB3816903C1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAly/gskACgkQgFZKbJXz 1A3ebA/9EojWkAMP0rqg+jsNhMAU+islOWDWqdQNq/DGx2w+bYywgvRPmuLCdPDN qsDyvzM7kFw3Z83VuvN80slXdxMX4JfXVE9UnR1rn72/PC0niAR4rM06Xf+9caHo 0EyyFMDGpfMurGR+4i45NBJvnzDtWnk2vCsv16fu/oH2+ad6qhLFcU/0CZzZim8f tIsZlxPlYfyuJiNPUrGd97MISveUsRzmYkQBkytAXhwGZupZ8iWWVB2o0TVesC2P DLE5mjHE5RjqSnepcAGWJq3jeHSZXIhS4bbwNMfsDWJl4y3PsZQ5hm/oP2LMhRBN rDfWNAB+mqywl7BvjoWVnk9cH7AMvhWoCSGmZjMGtd70dV2RZp4CSM9zorlggbRG aMJX5GTEeSn7KV22ikQPYAEHt+BqpTLwBndRgf7U9shlHav5rgFlQTL+Vc13CxlG naGZg5i8N+I9WkE6Q+pSP3cus4NYc5NNUy892GlZXGCr070w9I5z+i8ehUqlU8eo zSYqd1/yoGBYN6XHRVfFvjJr1xy4MAPbWovSnoX29fiu30QZp6GkoBzzYLVqdDAi agq/r3XrCSIqsb93ww/+Fr7SFNe0zZDGln7a4lftxh79JH85s87Of1l6Y37Rjz5a 06WL1ACMhWExbQVqp2MKirueXGX7x06pKxDStkqyvp1MGJk9kVE= =VJVD -----END PGP SIGNATURE----- --Apple-Mail=_D838564B-C27A-492D-992D-4EB3816903C1-- From nobody Thu Apr 25 04:07:34 2019 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED27120176; Thu, 25 Apr 2019 04:07:32 -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 Lydf-A9EGwqy; Thu, 25 Apr 2019 04:07:30 -0700 (PDT) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 61DFA120161; Thu, 25 Apr 2019 04:07:30 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id s2so12231529vsi.5; Thu, 25 Apr 2019 04:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jvQRnGgE26CqqwtL8ZawayGcmINJCZu3Dnt+pkKR5lk=; b=uUUoB+plnKbsV6wQvpvvr1FH8pNsW0tCqmg6d1KrKhpWsrag2NxkJoJOpc2RmW5ntx 1O/80iiFGtHUO7HjghUKNuzw/Oi1LOUoCB1sSLxMBL6hAHZBNctAiMe9/p6/J+gMZny7 N9v3qqFH/1xjarBIGjqEvBtwx8EYidbY7DAE1M4b2aAUjn03iffaT4UOOoSAPalqjDHC HFQ4CSeI0AL2GVq9ri+VHkEs6SI42lka9HlQC2lXHMkpiN75POphiQniFeHtvqbL3h6b vpIZyhFWBqgMRp0/yA5M09Z0qUsUdqZA4RbVGYyS8IOKXr+wcjnGLt7Wt3Mdh4AaUOkB 02GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jvQRnGgE26CqqwtL8ZawayGcmINJCZu3Dnt+pkKR5lk=; b=sxlgcA0woQGVbG3uTlMF2bfGPL/vRXYnRWoORedqRV8oGSogJEejIrvQBdGjoTkjdK Q9PtQ/2GL0/XW0PA52ktZyrxompBSSAb33AWhA7AcnFLOcT8d7/QQHnPKPHyaUoN0c7R HTZ4o9YBE5u+6/VjYbdcepPLStpFJ4CC9+N+CzRKA4vUO8XlzX2y3ucKP4jHadQHkG3O /nSvojNbMBnho/H5EfqPdZgXrjD9sOvNxyt24Cnr06Wwjoicw8QNJYFgzglPoroBRhx4 AeJPO4g2X36L7lqKQyx+WIMT0nglR6wojWko+xZXnTBxGCIJu9Se5WjqhrC6btmKZZr0 okxA== X-Gm-Message-State: APjAAAUMcI6+PWnzcDAJPEBIadchJfKc+aqscfuBLe6Yt2n3jS4Jwkn4 fkOEaxdyVGI8F55ChF7vyl7iWUSbbv/Uo5C2Es4= X-Google-Smtp-Source: APXvYqwq4c6Nw85O6flkuudorTjv8mP0L6oTBK5BXA9t7HSVUkvp0isTHEMVyeasjkbnq9VDa++kc8OZOJcr+1EhLG0= X-Received: by 2002:a67:ec8a:: with SMTP id h10mr3952763vsp.126.1556190448673; Thu, 25 Apr 2019 04:07:28 -0700 (PDT) MIME-Version: 1.0 References: <72C42C63-D5C4-403D-A895-429CB2238AC3@nostrum.com> <741719ee-bbc6-adaf-a036-8fdd655e470f@ericsson.com> In-Reply-To: From: Andy Hutton Date: Thu, 25 Apr 2019 12:07:19 +0100 Message-ID: To: Ben Campbell Cc: Gonzalo Camarillo , "sipbrandy@ietf.org" , "draft-ietf-sipbrandy-osrtp.all@ietf.org" , ART ADs Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-osrtp-07 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 11:07:33 -0000 Thanks Ben for suggesting text. I would be happy to add the text Ben suggested to the security considerations section if that is what is needed to get this done. Regards Andy On Tue, 23 Apr 2019 at 22:25, Ben Campbell wrote: > > (Please keep in mind I am no longer an AD; at this point my concern shoul= d be treated like last call feedback.) > > The issue with SDES is that, while SDES says messages with =E2=80=9Ca=3Dc= rypto=E2=80=9D SHOULD be protected end-to-end, and that hop-by-hop things s= uch as TLS and IPSec SHOULD NOT be used across with intermediaries, in prac= tice that SHOULD and SHOULD NOT are routinely ignored. > > I don=E2=80=99t think this requires a huge change. I propose adding a par= agraph to the effect of the following before the current last paragraph in = section 4: > > =E2=80=9CWhile OSRTP does not require authentication of the key-agreement= mechanism, it does need them to avoid exposing > SRTP keys to eavesdroppers, since this could enable passive attacks again= st SRTP. Section 8.3 of [RFC4568] requires that any messages that contain = SRTP keys be encrypted, and further says that encryption =E2=80=9CSHOULD=E2= =80=9D provide end-to-end confidentiality protection if intermediaries tha= t could inspect the SDP message are present. At the time of this writing, t= hat =E2=80=9CSHOULD=E2=80=9D is commonly ignored. Therefore, if OSRTP is us= ed with Security Descriptions, any such intermediaries (e.g., SIP proxies) = must be assumed to have access to the SRTP keys.=E2=80=9D > > Thanks! > > Ben. > > > > > On Apr 8, 2019, at 5:47 AM, Andy Hutton wro= te: > > > > I looked at this again and I am not convinced that any further changes > > to the draft are needed but if someone wants to suggest text then I > > can include it in the draft. > > > > In the case of SDES the security considerations states that an > > encrypted signalling channel must still be used so this draft changes > > nothing with respect to intermediaries and the SDES (RFC 4568) > > security considerations still apply. > > > > Regards > > Andy > > > > On Tue, 2 Apr 2019 at 14:56, Gonzalo Camarillo > > wrote: > >> > >> Hi Andy, > >> > >> Ben's response below indicates that his main substantive comment was n= ot > >> addressed in the revision you submitted last week. Could you please lo= ok > >> into it and get back to Ben? Thanks! > >> > >>>> With regard to Ben's comment on the relaxing of the authentication > >>>> requirement then this is consistent with the Opportunistic > >>>> Security RFC 7435 and I added a reference to this as > >>>> clarification. > >>> > >>> If I recall correctly, RFC 7435 does not discuss scenarios with > >>> separate signaling and media channels, and how OS applies to each > >>> channel. I was looking more for something about the impacts of this > >>> =E2=80=9Crelaxation=E2=80=9D specific to these sorts of scenarios wit= h dtls-srtp and > >>> sdes, and resulting assurances. > >>> > >>> For example, dtls-srtp with no authentication does not give you > >>> assurances about who you are talking to, but it still allows > >>> encryption. SDES without encryption lets an eavesdropper potentially > >>> learn the encryption keys, etc. SDES with transport level protection > >>> (e.g. SIPS) protects from off-path eavesdroppers, but allows proxies > >>> and b2bua=E2=80=99s in the signaling path to learn the encryption key= s. > >> > >> > >> Cheers, > >> > >> Gonzalo > >> > >> On 02-Apr-19 16:50, Andy Hutton wrote: > >>> I believe all Ben's points are addressed in the draft I submitted > >>> last week https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-08 > >>> > >>> Regards Andy > >>> > >>> On Tue, 2 Apr 2019 at 12:03, Gonzalo Camarillo > >>> wrote: > >>>> > >>>> Hi Andy, authors, > >>>> > >>>> could you please let Alexey when he should expect a new revision of > >>>> this draft that addresses Ben's point below? > >>>> > >>>> Cheers, > >>>> > >>>> Gonzalo > >>>> > >>>> On 26-Mar-19 18:10, Ben Campbell wrote: > >>>>> (+Alexey, who will take over SIPBRANDY when I step down as AD) > >>>>> > >>>>> Hi, > >>>>> > >>>>> Thanks for the response. This does not quite address my main > >>>>> substantive comment. It does address everything else :-) > >>>>> > >>>>> Please see comment in line. > >>>>> > >>>>> Thanks! > >>>>> > >>>>> Ben. > >>>>> > >>>>>> On Mar 26, 2019, at 11:58 AM, Andy Hutton > >>>>>> wrote: > >>>>>> > >>>>>> I submitted an update in response to Ben's comments - > >>>>>> https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-08 > >>>>>> > >>>>>> With regard to Ben's comment on the relaxing of the > >>>>>> authentication requirement then this is consistent with the > >>>>>> Opportunistic Security RFC 7435 and I added a reference to this > >>>>>> as clarification. > >>>>> > >>>>> If I recall correctly, RFC 7435 does not discuss scenarios with > >>>>> separate signaling and media channels, and how OS applies to each > >>>>> channel. I was looking more for something about the impacts of > >>>>> this =E2=80=9Crelaxation=E2=80=9D specific to these sorts of scenar= ios with > >>>>> dtls-srtp and sdes, and resulting assurances. > >>>>> > >>>>> For example, dtls-srtp with no authentication does not give you > >>>>> assurances about who you are talking to, but it still allows > >>>>> encryption. SDES without encryption lets an eavesdropper > >>>>> potentially learn the encryption keys, etc. SDES with transport > >>>>> level protection (e.g. SIPS) protects from off-path > >>>>> eavesdroppers, but allows proxies and b2bua=E2=80=99s in the signal= ing > >>>>> path to learn the encryption keys. > >>>>> > >>>>> > >>>>>> > >>>>>> Hopefully we can get this to RFC status now. > >>>>>> > >>>>>> Regards Andy > >>>>>> > >>>>>> On Mon, 25 Mar 2019 at 22:26, Andy Hutton > >>>>>> wrote: > >>>>>>> > >>>>>>> Sorry about the delay. > >>>>>>> > >>>>>>> See below. > >>>>>>> > >>>>>>> I will update the draft. > >>>>>>> > >>>>>>> Andy > >>>>>>> > >>>>>>> On Fri, 15 Feb 2019 at 08:46, Gonzalo Camarillo > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> Thanks for the quick review, Ben! > >>>>>>>> > >>>>>>>> Authors, please address Ben's comments below. > >>>>>>>> > >>>>>>>> Cheers, > >>>>>>>> > >>>>>>>> Gonzalo > >>>>>>>> > >>>>>>>> On 14-Feb-19 22:46, Ben Campbell wrote: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> This is my AD Evaluation of > >>>>>>>>> draft-ietf-sipbrandy-osrtp-07. > >>>>>>>>> > >>>>>>>>> Thank you for a readable and easy to understand > >>>>>>>>> document.There is one comment I would like to resolve > >>>>>>>>> prior to IETF LC. The others can be resolved along with > >>>>>>>>> any last call feedback. > >>>>>>>>> > >>>>>>>>> *** Please resolve prior to IETF LC *** > >>>>>>>>> > >>>>>>>>> =C2=A74: The relaxation of authentication requirements for > >>>>>>>>> DTLS-SRTP and SDES could use some elaboration on why this > >>>>>>>>> acceptable. I _think_ the answer is that, since OSRTP > >>>>>>>>> doesn=E2=80=99t guaranty authentication, there=E2=80=99s no nee= d for such > >>>>>>>>> a guaranty from the signaling channel. Is that correct? > >>>>>>>>> > >>>>>>>>> OTOH, =C2=A71 says "third mode for security between > >>>>>>>>> "cleartext=E2=80=9D and "comprehensive protection" that allows > >>>>>>>>> encryption and authentication to be used if supported=E2=80=A6= =E2=80=9D. > >>>>>>>>> That suggests that that authentication is sometimes > >>>>>>>>> provided. Is there a distinction between the > >>>>>>>>> authenticated case and unauthenticated case that should > >>>>>>>>> be mentioned somewhere? (For example, is there a need to > >>>>>>>>> indicate the distinction to the user?) > >>>>>>>>> > >>>>>>> > >>>>>>> $1 should I think say "allows encryption and authenticated > >>>>>>> media" but I cannot remember why we said the signalling > >>>>>>> authentication requirements are relaxed this has been in the > >>>>>>> draft from day 1 and I guess it is consistent with the best > >>>>>>> effort approach. > >>>>>>> > >>>>>>> Anyone else want to comment? > >>>>>>> > >>>>>>> > >>>>>>>>> *** Other Substantive Comments *** > >>>>>>>>> > >>>>>>>>> =C2=A72: Please use the new boilerplate from RFC 8174. > >>>>>>> > >>>>>>> Will do. > >>>>>>> > >>>>>>>>> > >>>>>>>>> =C2=A73.1: Please clarify that that the offer can contain more > >>>>>>>>> than one key management attribute. This is mentioned in > >>>>>>>>> =C2=A73.1, but not actually in the section on generating the > >>>>>>>>> offer. > >>>>>>> > >>>>>>> Will do. > >>>>>>> > >>>>>>>>> > >>>>>>>>> *** Editorial Comments *** > >>>>>>>>> > >>>>>>>>> =C2=A73: "As discussed in [RFC7435], this is the > >>>>>>>>> "comprehensive protection" for media mode.=E2=80=9D s/this/that > >>>>>>> > >>>>>>> Thanks > >>>>>>> > >>>>>>>>> > >>>>>>>>> =C2=A73.4: "meaning that the decision to create an OSRTP type > >>>>>>>>> offer or something else should not be influenced=E2=80=9D That= =E2=80=99s > >>>>>>>>> referring to the decision to create a _new_ offer, right? > >>>>>>>>> Not the original offer? > >>>>>>> > >>>>>>> Correct. > >>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ Sipbrandy > >>>>>>>>> mailing list Sipbrandy@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/sipbrandy > >>>>>>>>> > >>>>>>>> _______________________________________________ Sipbrandy > >>>>>>>> mailing list Sipbrandy@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/sipbrandy > >>>>> > >>>> > >>> > >>> _______________________________________________ Sipbrandy mailing > >>> list Sipbrandy@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipbrandy > >>> > From nobody Thu Apr 25 16:21:55 2019 Return-Path: X-Original-To: sipbrandy@ietf.org Delivered-To: sipbrandy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EBE120073; Thu, 25 Apr 2019 16:21:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipbrandy@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sipbrandy@ietf.org Message-ID: <155623450715.19244.1327926016847527378@ietfa.amsl.com> Date: Thu, 25 Apr 2019 16:21:47 -0700 Archived-At: Subject: [Sipbrandy] I-D Action: draft-ietf-sipbrandy-rtpsec-08.txt X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 23:21:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP Best-practice Recommendations Against Network Dangers to privacY WG of the IETF. Title : Best Practices for Securing RTP Media Signaled with SIP Authors : Jon Peterson Richard Barnes Russ Housley Filename : draft-ietf-sipbrandy-rtpsec-08.txt Pages : 14 Date : 2019-04-25 Abstract: Although the Session Initiation Protocol (SIP) includes a suite of security services that has been expanded by numerous specifications over the years, there is no single place that explains how to use SIP to establish confidential media sessions. Additionally, existing mechanisms have some feature gaps that need to be identified and resolved in order for them to address the pervasive monitoring threat model. This specification describes best practices for negotiating confidential media with SIP, including a comprehensive protection solution that binds the media layer to SIP layer identities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-rtpsec/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipbrandy-rtpsec-08 https://datatracker.ietf.org/doc/html/draft-ietf-sipbrandy-rtpsec-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipbrandy-rtpsec-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 26 03:45:48 2019 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695731203A5 for ; Fri, 26 Apr 2019 03:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 qUY64R70NozQ for ; Fri, 26 Apr 2019 03:45:42 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD63120457 for ; Fri, 26 Apr 2019 03:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1556275539; x=1558867539; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3ffcnFeCxHaKY4R8exwShRFWQqgzFAyQaQPyY1mYSFc=; b=f5Hm0jeebdVe1+VnmlMbyQqRG5MCcolIpJNj0lCd+6/E09B2CYGg5VKP/dAcIYzL W+Hqml6YXJBQGLAsSRy8fJq0fbjrIK8GgatEwkBPeMSckO2rrmxe/KKs7TWX0el2 JBFrZR2CBHmoJP7wCoykJr7/cp/a6kpD37F4nRIT8yM=; X-AuditID: c1b4fb2d-195ff70000001a6d-bb-5cc2e153f7ea Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 51.17.06765.351E2CC5; Fri, 26 Apr 2019 12:45:39 +0200 (CEST) Received: from ESESSMR504.ericsson.se (153.88.183.126) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 26 Apr 2019 12:45:39 +0200 Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMR504.ericsson.se (153.88.183.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 26 Apr 2019 12:45:39 +0200 Received: from [100.120.234.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.186) with Microsoft SMTP Server id 15.1.1713.5 via Frontend Transport; Fri, 26 Apr 2019 12:45:38 +0200 To: Andy Hutton , Ben Campbell CC: "sipbrandy@ietf.org" , "draft-ietf-sipbrandy-osrtp.all@ietf.org" , ART ADs References: <72C42C63-D5C4-403D-A895-429CB2238AC3@nostrum.com> <741719ee-bbc6-adaf-a036-8fdd655e470f@ericsson.com> From: Gonzalo Camarillo Openpgp: preference=signencrypt Autocrypt: addr=Gonzalo.Camarillo@ericsson.com; prefer-encrypt=mutual; keydata= xsBNBEtSyYUBCADL7itybUN0VVtGQuO81AdviJNSo/BIc6xuVUofHlr/U9CbQcSrRSggvTfa 6n5o9t9zAuwp9pp+hQfSzn4/LrEaV2BmEfAFclSl57IhsXDJecw58JqGZrjahIjgU+rmZKPE RqLzubmI3ltEolLb4kkB9Y8FIQBnE1N3O0wHp7BE8VI5pQX24UkRkEtUptmhwnaehURg9atb 1myxbt1nUDEA5PLJNbPeXxPRJ058OEnPtToRinSCJ7BFtD6PoeUWgOL4kKdRbMyswDikiXnN Ntj1VkDQ6yi7pOb2qkviOzKOf/smqm4ovMxUrET7SzKw4icArL+xQUW3ayJyfSju1o5rABEB AAHNJkdvbnphbG8gQ2FtYXJpbGxvIDxnY2FtYXJpbEBnbWFpbC5jb20+wsCBBBMBAgArAhsj BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAIZAQUCWhwGngUJFGzXmQAKCRDRM1CYcD+HNkjG CACG39D/tNsA5xxSqRtN3JJCTfpj+BWqRckMEpBjBWlOOtb94QY8r9NHRIDwvA5qCVYRqQTI qVyReNw/CkOuaah2rbCdhsng6ZAMzFovXSEnbz+wse4QiKybHvjlJJA9qQiNlne57NVlNvLN LrpZJGmSJlJBBEQRq3Z9Crl2tWFkB6mmoXNnoRej6eVmhFoAo3td5loHo55nqYVZYtAHbXan ggmPI12gUigKf4PuvIISpdokSlkpam02Y61ygtqrlYvNnM+GpbayW2X3ZY5x6bwUwfkRSUCj +xslGaRfJUwr8kUxhVlcLR6qVcjNxWeZf9XKVH86OxEJVUVFsChlDAvHzsBNBEtSyYUBCADB qzP0B7lWge5Hn1648WPWrmUg8r3723XL/zUZe1zyEVsY9VyWhrBmuEy7Xm7wdLt0+BBXWJez 7/wWR9w/63qT+3+W0fe6SDXeZqF+HtYO5QPuu/VYtex0e3TI2w4s53ZM5KQCQF60kTDoK43e 5a6/G2GCKMPpkVKxpIeOiDITiRXq9GV7KHkQpPczqj9ImWp2M9sEIngZRaKILU//TaiWnRGR i6vN/sAvfEuu1fXTwpR6bBdD9wIZgyeSqEgxnioDdyFZYkTFl9G8TuLxNIdpVPzW2M9PKRQs i/kl/Kadsgnd8RtlP7cPoIqLMjmOfGwR8EVbKpmkM1+iKJ+g9F/bABEBAAHCwGUEGAECAA8C GwwFAlocBq4FCRRs16kACgkQ0TNQmHA/hzamwgf/Tnr7/WYnKNmEYvwr/GxhSelVYsBwejkz tCXa4gmVkErgPBEYsUtWAP+jVoYndG74v/3zBPHl4CehE9RnAJ+lpsWjwsn0qPI7sCik3Xqv c44g/RQF9RSI8DckQM0MqLJNazzq4tBi/ZbILWNx2N4LrEzhwoePug3MDn3rCv1Xpr/B60or p1zixtSRKyZo+L7UjttUdJkqxUbC35pBlZlDAL2Dop9He7XwUFofyW1Xvn9xxx0NasnlJX9G 288peTb41bQrs9SqaH1aVLXBTo7S9o+8oB9DLTIIwDQqfxqTWpGIfBhiTm9d7ai9WcFC8jSW zJtc/6luXoGjvUlBzQx0jQ== Message-ID: <8a1ab85c-0dd3-7db8-57ff-c7e76fffde62@ericsson.com> Date: Fri, 26 Apr 2019 13:45:38 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2J7qW7ww0MxBrN3q1tcWreVyWLj08ks FvM7T7Nb3Lh+js1ixbpTTA6sHjtn3WX3WLLkJ5PHrJ1PWAKYo7hsUlJzMstSi/TtErgy7n2e wFKwzq/i5df7TA2M0xy7GDk5JARMJBZ86GTpYuTiEBI4yijx9GQDM4TzjVFix/w1LCBVYM6P 3yVwVc0HljCDJIQF3CWuPzrEBGKLCHhLfHi8HGwUs8AiRomW1hVsEB1rWSWOLroFNopNwEJi y637YDa/gLxE14KrYJMYBe7xSkx4mg9i8wrYSzS9WAxWwyKgKjH/6HxWEFtUIFbi6/TpbBA1 ghInZz4Bq+EUCJTYseASUA0H0GZNifW79EHCzALiEreezGeCsOUlmrfOZob4Rlti85pTjBMY RWchmTQLoXsWku5ZSLoXMLKsYhQtTi0uzk03MtZLLcpMLi7Oz9PLSy3ZxAiMqYNbfuvuYFz9 2vEQowAHoxIP78lLh2KEWBPLiitzDzFKcDArifCqmx6MEeJNSaysSi3Kjy8qzUktPsQozcGi JM4bvXpPjJBAemJJanZqakFqEUyWiYNTqoGR5cTGNa6vTV91+/MrPdNOergmwvBtpmfQzWJ/ 7kmPVk0+YfsviXsK4/aMko+SObkx8T5Wc18/FPpwRC400LSq4FCKYZZCaOkjNlsLy4wfawTm nugNmXY9+cTK+Qr/2b/9C5wUJ9u/sMfmhG8p90wG5599PXMXXV14Jc7jkI1TI8P311zlzjOV WIozEg21mIuKEwEPmKZ8pQIAAA== Archived-At: Subject: Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-osrtp-07 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 10:45:47 -0000 Hi Andy, yes, please, go ahead revise the draft so that Ben's AD review is addressed. Alexey will take it from there. Cheers, Gonzalo On 25-Apr-19 14:07, Andy Hutton wrote: > Thanks Ben for suggesting text. > > I would be happy to add the text Ben suggested to the security > considerations section if that is what is needed to get this done. > > Regards > Andy > > > > On Tue, 23 Apr 2019 at 22:25, Ben Campbell wrote: >> >> (Please keep in mind I am no longer an AD; at this point my concern should be treated like last call feedback.) >> >> The issue with SDES is that, while SDES says messages with “a=crypto” SHOULD be protected end-to-end, and that hop-by-hop things such as TLS and IPSec SHOULD NOT be used across with intermediaries, in practice that SHOULD and SHOULD NOT are routinely ignored. >> >> I don’t think this requires a huge change. I propose adding a paragraph to the effect of the following before the current last paragraph in section 4: >> >> “While OSRTP does not require authentication of the key-agreement mechanism, it does need them to avoid exposing >> SRTP keys to eavesdroppers, since this could enable passive attacks against SRTP. Section 8.3 of [RFC4568] requires that any messages that contain SRTP keys be encrypted, and further says that encryption “SHOULD” provide end-to-end confidentiality protection if intermediaries that could inspect the SDP message are present. At the time of this writing, that “SHOULD” is commonly ignored. Therefore, if OSRTP is used with Security Descriptions, any such intermediaries (e.g., SIP proxies) must be assumed to have access to the SRTP keys.” >> >> Thanks! >> >> Ben. >> >> >> >>> On Apr 8, 2019, at 5:47 AM, Andy Hutton wrote: >>> >>> I looked at this again and I am not convinced that any further changes >>> to the draft are needed but if someone wants to suggest text then I >>> can include it in the draft. >>> >>> In the case of SDES the security considerations states that an >>> encrypted signalling channel must still be used so this draft changes >>> nothing with respect to intermediaries and the SDES (RFC 4568) >>> security considerations still apply. >>> >>> Regards >>> Andy >>> >>> On Tue, 2 Apr 2019 at 14:56, Gonzalo Camarillo >>> wrote: >>>> >>>> Hi Andy, >>>> >>>> Ben's response below indicates that his main substantive comment was not >>>> addressed in the revision you submitted last week. Could you please look >>>> into it and get back to Ben? Thanks! >>>> >>>>>> With regard to Ben's comment on the relaxing of the authentication >>>>>> requirement then this is consistent with the Opportunistic >>>>>> Security RFC 7435 and I added a reference to this as >>>>>> clarification. >>>>> >>>>> If I recall correctly, RFC 7435 does not discuss scenarios with >>>>> separate signaling and media channels, and how OS applies to each >>>>> channel. I was looking more for something about the impacts of this >>>>> “relaxation” specific to these sorts of scenarios with dtls-srtp and >>>>> sdes, and resulting assurances. >>>>> >>>>> For example, dtls-srtp with no authentication does not give you >>>>> assurances about who you are talking to, but it still allows >>>>> encryption. SDES without encryption lets an eavesdropper potentially >>>>> learn the encryption keys, etc. SDES with transport level protection >>>>> (e.g. SIPS) protects from off-path eavesdroppers, but allows proxies >>>>> and b2bua’s in the signaling path to learn the encryption keys. >>>> >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >>>> On 02-Apr-19 16:50, Andy Hutton wrote: >>>>> I believe all Ben's points are addressed in the draft I submitted >>>>> last week https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-08 >>>>> >>>>> Regards Andy >>>>> >>>>> On Tue, 2 Apr 2019 at 12:03, Gonzalo Camarillo >>>>> wrote: >>>>>> >>>>>> Hi Andy, authors, >>>>>> >>>>>> could you please let Alexey when he should expect a new revision of >>>>>> this draft that addresses Ben's point below? >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Gonzalo >>>>>> >>>>>> On 26-Mar-19 18:10, Ben Campbell wrote: >>>>>>> (+Alexey, who will take over SIPBRANDY when I step down as AD) >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Thanks for the response. This does not quite address my main >>>>>>> substantive comment. It does address everything else :-) >>>>>>> >>>>>>> Please see comment in line. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Ben. >>>>>>> >>>>>>>> On Mar 26, 2019, at 11:58 AM, Andy Hutton >>>>>>>> wrote: >>>>>>>> >>>>>>>> I submitted an update in response to Ben's comments - >>>>>>>> https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-08 >>>>>>>> >>>>>>>> With regard to Ben's comment on the relaxing of the >>>>>>>> authentication requirement then this is consistent with the >>>>>>>> Opportunistic Security RFC 7435 and I added a reference to this >>>>>>>> as clarification. >>>>>>> >>>>>>> If I recall correctly, RFC 7435 does not discuss scenarios with >>>>>>> separate signaling and media channels, and how OS applies to each >>>>>>> channel. I was looking more for something about the impacts of >>>>>>> this “relaxation” specific to these sorts of scenarios with >>>>>>> dtls-srtp and sdes, and resulting assurances. >>>>>>> >>>>>>> For example, dtls-srtp with no authentication does not give you >>>>>>> assurances about who you are talking to, but it still allows >>>>>>> encryption. SDES without encryption lets an eavesdropper >>>>>>> potentially learn the encryption keys, etc. SDES with transport >>>>>>> level protection (e.g. SIPS) protects from off-path >>>>>>> eavesdroppers, but allows proxies and b2bua’s in the signaling >>>>>>> path to learn the encryption keys. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Hopefully we can get this to RFC status now. >>>>>>>> >>>>>>>> Regards Andy >>>>>>>> >>>>>>>> On Mon, 25 Mar 2019 at 22:26, Andy Hutton >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Sorry about the delay. >>>>>>>>> >>>>>>>>> See below. >>>>>>>>> >>>>>>>>> I will update the draft. >>>>>>>>> >>>>>>>>> Andy >>>>>>>>> >>>>>>>>> On Fri, 15 Feb 2019 at 08:46, Gonzalo Camarillo >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Thanks for the quick review, Ben! >>>>>>>>>> >>>>>>>>>> Authors, please address Ben's comments below. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> >>>>>>>>>> Gonzalo >>>>>>>>>> >>>>>>>>>> On 14-Feb-19 22:46, Ben Campbell wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> This is my AD Evaluation of >>>>>>>>>>> draft-ietf-sipbrandy-osrtp-07. >>>>>>>>>>> >>>>>>>>>>> Thank you for a readable and easy to understand >>>>>>>>>>> document.There is one comment I would like to resolve >>>>>>>>>>> prior to IETF LC. The others can be resolved along with >>>>>>>>>>> any last call feedback. >>>>>>>>>>> >>>>>>>>>>> *** Please resolve prior to IETF LC *** >>>>>>>>>>> >>>>>>>>>>> §4: The relaxation of authentication requirements for >>>>>>>>>>> DTLS-SRTP and SDES could use some elaboration on why this >>>>>>>>>>> acceptable. I _think_ the answer is that, since OSRTP >>>>>>>>>>> doesn’t guaranty authentication, there’s no need for such >>>>>>>>>>> a guaranty from the signaling channel. Is that correct? >>>>>>>>>>> >>>>>>>>>>> OTOH, §1 says "third mode for security between >>>>>>>>>>> "cleartext” and "comprehensive protection" that allows >>>>>>>>>>> encryption and authentication to be used if supported…”. >>>>>>>>>>> That suggests that that authentication is sometimes >>>>>>>>>>> provided. Is there a distinction between the >>>>>>>>>>> authenticated case and unauthenticated case that should >>>>>>>>>>> be mentioned somewhere? (For example, is there a need to >>>>>>>>>>> indicate the distinction to the user?) >>>>>>>>>>> >>>>>>>>> >>>>>>>>> $1 should I think say "allows encryption and authenticated >>>>>>>>> media" but I cannot remember why we said the signalling >>>>>>>>> authentication requirements are relaxed this has been in the >>>>>>>>> draft from day 1 and I guess it is consistent with the best >>>>>>>>> effort approach. >>>>>>>>> >>>>>>>>> Anyone else want to comment? >>>>>>>>> >>>>>>>>> >>>>>>>>>>> *** Other Substantive Comments *** >>>>>>>>>>> >>>>>>>>>>> §2: Please use the new boilerplate from RFC 8174. >>>>>>>>> >>>>>>>>> Will do. >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> §3.1: Please clarify that that the offer can contain more >>>>>>>>>>> than one key management attribute. This is mentioned in >>>>>>>>>>> §3.1, but not actually in the section on generating the >>>>>>>>>>> offer. >>>>>>>>> >>>>>>>>> Will do. >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *** Editorial Comments *** >>>>>>>>>>> >>>>>>>>>>> §3: "As discussed in [RFC7435], this is the >>>>>>>>>>> "comprehensive protection" for media mode.” s/this/that >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> §3.4: "meaning that the decision to create an OSRTP type >>>>>>>>>>> offer or something else should not be influenced” That’s >>>>>>>>>>> referring to the decision to create a _new_ offer, right? >>>>>>>>>>> Not the original offer? >>>>>>>>> >>>>>>>>> Correct. >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ Sipbrandy >>>>>>>>>>> mailing list Sipbrandy@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipbrandy >>>>>>>>>>> >>>>>>>>>> _______________________________________________ Sipbrandy >>>>>>>>>> mailing list Sipbrandy@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipbrandy >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ Sipbrandy mailing >>>>> list Sipbrandy@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipbrandy >>>>> >>