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

Andy Hutton <andyhutton.ietf@gmail.com> Wed, 01 May 2019 11:39 UTC

Return-Path: <andyhutton.ietf@gmail.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 83FD3120103; Wed, 1 May 2019 04:39:59 -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 cugHlk4B74o1; Wed, 1 May 2019 04:39:56 -0700 (PDT)
Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 770031200F1; Wed, 1 May 2019 04:39:56 -0700 (PDT)
Received: by mail-ua1-x936.google.com with SMTP id 88so5743884uau.6; Wed, 01 May 2019 04:39:56 -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=xfi2VbJr9NNxxXxvnqqX4O6JLNse7G4LF/o0ACCGVuo=; b=gT0aYBPeIpRVu6qcRnl2RldA3w96ZnEg9T4Caa20vNiZAjEOACOqnb4datEF3Rbxlo THEv3b1wFXsYV9IcCKqI1DhtPqPgiWma7ODwxVnG6j8sikarKcjWtPCFFV/K/JPNwG/L z1wlR2xaZMtuBdnT2CHnAJuhJozzwhgscQ4hY7eyrn9UjC4BvhNzecGTH159PKLtepIZ xeXk8Qw/GuaXooLh0Tsi/VBLPY0vGZmYGBGBLHpWIP8AeIPgbUL3Ve487QeBEaYpmg7I qY+u29nO/RsdJXN/YzGrda20n4t5j0dJIGABRLirST05C5Z1LO1ydjqvU1Lp9w0od6H1 4RNA==
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=xfi2VbJr9NNxxXxvnqqX4O6JLNse7G4LF/o0ACCGVuo=; b=TmQk3Cp3D6RIYzcUa2xQTZs13Y6yOhIiQkXC/FR7JFpJb2k6NKGSWZHpqFLqOmQvqT HEKnghZfvu+974dtZ3Tx/r7OVks1bbNA7zOIcsIN/vi0shJMNohe+Lkw4GqJojBlwpv7 tU+8lyq/+jpR9AzBJvZHiNQ1fodxCM8CQAJqMG+6a7NpXHOUnhcKJgYlljEDmpSg5mjr Cf7YJrLjvkHNRl1TblbeufPPUysA2lOnFs1LBvFVMoFgTbxoJiibLx2Q+WUZTQ5EYT9h JAQ8Lyq1kyJD8mPCEs2QzSSl+zyC1e9hFgkRjw679nxSLMkL9YCbIOj6JZNM+ljQn5ae f2ww==
X-Gm-Message-State: APjAAAVogXendiBn1hD73qNVAD6TKKMGr99gtQgBbZhnOZooTJP8diYV Sbx9yDIyFTuhKO0VuDB27HP/5QHeikOesDw94O7/ltZhqgo=
X-Google-Smtp-Source: APXvYqyWWXohK+OnYQS6nUd9fJgTE0V6i/RgzwldjOuEz9qTnrX72NgOAyCwe7yF6vq41FoVnPp065KSYHI4wZ/T58Y=
X-Received: by 2002:ab0:25cc:: with SMTP id y12mr3597909uan.113.1556710795403; Wed, 01 May 2019 04:39:55 -0700 (PDT)
MIME-Version: 1.0
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> <FBD2D501-6126-4FA0-B9BA-1BC042F529E2@nostrum.com> <CAB7PXwQYWrkhdM9LBiso++axdMyu2p08WG8K59Q1PaYJWbvn_A@mail.gmail.com> <8a1ab85c-0dd3-7db8-57ff-c7e76fffde62@ericsson.com>
In-Reply-To: <8a1ab85c-0dd3-7db8-57ff-c7e76fffde62@ericsson.com>
From: Andy Hutton <andyhutton.ietf@gmail.com>
Date: Wed, 1 May 2019 12:39:44 +0100
Message-ID: <CAB7PXwTMfzbGVQV9VYSpcD9nmxSuCBvSj=_dpNjrCdS=rzd+tg@mail.gmail.com>
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.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>, ART ADs <art-ads@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipbrandy/d0QM92FybOptPXoyEIr3QwbMZJw>
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: Wed, 01 May 2019 11:40:00 -0000

Done.

The -09 draft has been submitted with text suggested by Ben, with
minor tweaks from me, in the security considerations section.

https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-09


Regards

Andy

On Fri, 26 Apr 2019 at 11:45, Gonzalo Camarillo
<Gonzalo.Camarillo@ericsson.com> wrote:
>
> 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 <ben@nostrum.com> 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 <andyhutton.ietf@gmail.com> 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
> >>>>>
> >>