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

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Mon, 08 April 2019 10:49 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 D75271200B8 for <sipbrandy@ietfa.amsl.com>; 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 <sipbrandy@ietfa.amsl.com>; 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 <sipbrandy@ietf.org>; 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 <andyhutton.ietf@gmail.com>
CC: Ben Campbell <ben@nostrum.com>, "sipbrandy@ietf.org" <sipbrandy@ietf.org>, "draft-ietf-sipbrandy-osrtp.all@ietf.org" <draft-ietf-sipbrandy-osrtp.all@ietf.org>, Alexey Melnikov <Alexey.Melnikov@isode.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> <c28ee3c0-b91d-3a12-e83b-4d3b727fc908@ericsson.com> <CAB7PXwRtAd1OC6r0AGJZ66km=ei_fq80QYUUuNbZuQGT4HmPkQ@mail.gmail.com> <741719ee-bbc6-adaf-a036-8fdd655e470f@ericsson.com> <CAB7PXwTkkN0905aHREPyoCX0YY1+adr9sbrVnGuPFp-Rgk3ONw@mail.gmail.com>
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
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: <CAB7PXwTkkN0905aHREPyoCX0YY1+adr9sbrVnGuPFp-Rgk3ONw@mail.gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/sipbrandy/1q0xHNVAvLpZoJ112DOQejai0JE>
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: 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
> <gonzalo.camarillo@ericsson.com> 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
>>> <gonzalo.camarillo@ericsson.com> 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
>>>>>> <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
>>>>>
>>>>
>>>
>>> _______________________________________________ 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
>