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

Ben Campbell <ben@nostrum.com> Tue, 23 April 2019 20:44 UTC

Return-Path: <ben@nostrum.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 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 <ben@nostrum.com>
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 <andyhutton.ietf@gmail.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>
To: Gonzalo Camarillo <Gonzalo.Camarillo@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> <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> <2e599cba-8f58-d1e5-3387-28013b26302d@ericsson.com>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipbrandy/OnhfSTDgG3CmygvVZ9Lnlit9uXc>
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, 23 Apr 2019 20:44:44 -0000

I will respond separately to Andy’s email. But please keep in mind I am no longer the responsible AD, and it’s up to Alexey to decide how to move forward.

Thanks!

Ben.

> On Apr 8, 2019, at 5:49 AM, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> wrote:
> 
> 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
>>