Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-osrtp-07

Gonzalo Camarillo <gonzalo.camarillo@ericsson.com> Tue, 02 April 2019 11:03 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
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 <gonzalo.camarillo@ericsson.com>
To: Ben Campbell <ben@nostrum.com>, Andy Hutton <andyhutton.ietf@gmail.com>
CC: "draft-ietf-sipbrandy-osrtp.all@ietf.org" <draft-ietf-sipbrandy-osrtp.all@ietf.org>, "sipbrandy@ietf.org" <sipbrandy@ietf.org>, Alexey Melnikov <Alexey.Melnikov@isode.com>
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: <c28ee3c0-b91d-3a12-e83b-4d3b727fc908@ericsson.com>
References: <72C42C63-D5C4-403D-A895-429CB2238AC3@nostrum.com> <e6724bd0-1ea0-3014-8836-60dc454c2982@ericsson.com> <CAB7PXwTUXUa1Euar+hXY4EzOqZ0_U-eru=e1ApjTy4a2FCBYJg@mail.gmail.com> <CAB7PXwRSFXcB5zGdNP_zqyKWUJqZAK+bKsxeyWhK6eeogqJ8dw@mail.gmail.com> <A7A08115-5B69-4931-8C89-0EBDF3A76D10@nostrum.com>
In-Reply-To: <A7A08115-5B69-4931-8C89-0EBDF3A76D10@nostrum.com>
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: <HE1PR0702MB3722529E5747D76E2FA0632983560@HE1PR0702MB3722.eurprd07.prod.outlook.com>
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: <https://mailarchive.ietf.org/arch/msg/sipbrandy/Mdvx15iHJq5SZBuiV3FJm-DqiIY>
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 <sipbrandy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipbrandy>, <mailto:sipbrandy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipbrandy/>
List-Post: <mailto:sipbrandy@ietf.org>
List-Help: <mailto:sipbrandy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipbrandy>, <mailto:sipbrandy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2019 11:03:29 -0000

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 <andyhutton.ietf@gmail.com> 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 <andyhutton.ietf@gmail.com> wrote:
>>>
>>> Sorry about the delay.
>>>
>>> See below.
>>>
>>> I will update the draft.
>>>
>>> Andy
>>>
>>> On Fri, 15 Feb 2019 at 08:46, Gonzalo Camarillo
>>> <gonzalo.camarillo@ericsson.com> 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
>