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 >>
- [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy… Ben Campbell
- Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbr… Gonzalo Camarillo
- Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbr… Ben Campbell
- Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbr… Gonzalo Camarillo
- Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbr… Andy Hutton
- Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbr… Andy Hutton
- Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbr… Ben Campbell
- Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbr… Gonzalo Camarillo
- Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbr… Andy Hutton
- Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbr… Gonzalo Camarillo
- Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbr… Andy Hutton
- Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbr… Gonzalo Camarillo
- Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbr… Gonzalo Camarillo
- Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbr… Ben Campbell
- Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbr… Ben Campbell
- Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbr… Andy Hutton
- Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbr… Gonzalo Camarillo
- Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbr… Andy Hutton