Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-double-10: (with DISCUSS and COMMENT)
Richard Barnes <rlb@ipv.sx> Thu, 29 August 2019 14:30 UTC
Return-Path: <rlb@ipv.sx>
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7016A1200C3 for <perc@ietfa.amsl.com>; Thu, 29 Aug 2019 07:30:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 QGKV3vM1g2S3 for <perc@ietfa.amsl.com>; Thu, 29 Aug 2019 07:30:05 -0700 (PDT)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 B7C6D120025 for <perc@ietf.org>; Thu, 29 Aug 2019 07:30:05 -0700 (PDT)
Received: by mail-ot1-x330.google.com with SMTP id b1so3594972otp.6 for <perc@ietf.org>; Thu, 29 Aug 2019 07:30:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eErlWzRtoK0GTjczWBW4leaP+g8UaHt63ReBCIxWzkw=; b=Gk1gbQpxC2yp+WqV24pZ+1ncQ10JhXgAR0yAbmxUmf7godbN4lQzUQs6gWgn163mhS dLtfmXBU2zVLdN+7xuhWB7g7yM02Ct+YaP1T4QNE/h0SJT9pt8fBMcOryfP6nEQgfViQ C0lY3HTKLYfCP3HuJXztPUEaHDUXKN0IrShq16wTTskr9hkehb+ZmcoV76luM4wBp54A gp2vYyPj6juWlOua5mkPfj/josb7O/ljpDGjPOalQ7hoOdDguKybT3vG7Inl8Q8NWLqi zygULRYqHINXbOJqNrakZpVDgP73p2dGCYBVOn5SlIqHa/Mxq/MF9fH7eg4iRgWnHasr ZmUA==
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; bh=eErlWzRtoK0GTjczWBW4leaP+g8UaHt63ReBCIxWzkw=; b=Cbqdsh4P3rkwShbVC3Dt8udLJv4hH2IzOvuQA3HAWvxgsceYpB6MmsT32/yXRlsKRA 9EMNGkIsWxx2BoTNiRnGKZcRIaX3wr4B9dm2O3qzWaTG2yqvZlofze5FMuIh5bWRLv5x oIPMpVHf0VvdsTeCD6b0olzRXSnY2tvpzDncDYZgF8q/mHVcHDNoxcKJNnT9AmnXdK93 dsbJkze1TQq+VH0JlZp1vrFhSrIGXLR6SD0MuwvijkNO+sRL+whdXocQv6ety5H+o2nk yT7KcfjR6e8j1S8BnMmJWtojhRpghu9hBgGfVw6nTA9pAdSOQPGpUGwtZspZPeK96F+E TPQw==
X-Gm-Message-State: APjAAAX+4lvWXkjrOj7Pl3dQHwrOMIHgD8iw10ZiKp7zhZK3kTrR1ZE0 OpdKevjrKCl0o/YBB7ZYIVBql1oWLR9cWStyWFoY1A==
X-Google-Smtp-Source: APXvYqyKfDdF3j7XbBzMYMJyFYH3ouwkMEBai3/wFphcGhYNmrl775o5MRHRSUl/eto1FsCqtRFfXZp+CzTIqoiNwwQ=
X-Received: by 2002:a05:6830:1bd4:: with SMTP id v20mr337422ota.159.1567089004813; Thu, 29 Aug 2019 07:30:04 -0700 (PDT)
MIME-Version: 1.0
References: <155800082724.19580.16483563575859435866.idtracker@ietfa.amsl.com> <65737EA1-49AF-4EB9-AD1F-25157B3F010D@iii.ca> <HE1PR0701MB25220714DB8E5AE970E0FDFA95DA0@HE1PR0701MB2522.eurprd07.prod.outlook.com> <CAL02cgTf9sMonRFG1qi9pLxuK8ruvxUStdcju8JU_9+5Kty53w@mail.gmail.com> <CAMRcRGT-izdwyuLX+kiPL5q5TnhoTKGw_9OJSvkDQo59JujS6w@mail.gmail.com> <5cec79c71d859aa95e352824320ad261f8525916.camel@ericsson.com> <CAL02cgRRckXWtuA_dnOLz7mvWEeDetW+2dqq5+sDBraDFLqqZg@mail.gmail.com> <b3d6130cd01a0a9f6b2c4b94df673c7fbf81a089.camel@ericsson.com>
In-Reply-To: <b3d6130cd01a0a9f6b2c4b94df673c7fbf81a089.camel@ericsson.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Thu, 29 Aug 2019 10:29:43 -0400
Message-ID: <CAL02cgQva1fUp5Fh1XSWot4R6fv3T+vRVUiAK7uocEt=0jvYbg@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Cc: "fluffy@iii.ca" <fluffy@iii.ca>, "perc@ietf.org" <perc@ietf.org>, "suhasietf@gmail.com" <suhasietf@gmail.com>, "iesg@ietf.org" <iesg@ietf.org>, "perc-chairs@ietf.org" <perc-chairs@ietf.org>, "draft-ietf-perc-double@ietf.org" <draft-ietf-perc-double@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000076ab88059142579a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/perc/pGivB6ljEEebzAwZjx7aqETgAhk>
Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-double-10: (with DISCUSS and COMMENT)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing <perc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perc>, <mailto:perc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/perc/>
List-Post: <mailto:perc@ietf.org>
List-Help: <mailto:perc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perc>, <mailto:perc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Aug 2019 14:30:09 -0000
draft-12 just posted. https://datatracker.ietf.org/doc/draft-ietf-perc-double/ On Thu, Aug 29, 2019 at 10:19 AM Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > I will clear when the new version is available or an RFC-editor note to > this affect has been included. > > Cheers > > Magnus > > On Thu, 2019-08-29 at 09:50 -0400, Richard Barnes wrote: > > Easy enough. I think RFC 3711 is clear enough, but if you want it to > > be more explicit, so it shall be. I just copied over the language > > from 3711. > > > > https://github.com/ietf/perc-wg/pull/174 > > > > > > > > On Thu, Aug 29, 2019 at 5:50 AM Magnus Westerlund < > > magnus.westerlund@ericsson.com> wrote: > > > Hi, > > > Hi, > > > > > > > > > Back from vacation. > > > > > > No Richards explanation doesn't help. Section 5.1 contains a > > > normative > > > description of how to create a synthetic packet. That description > > > is > > > not expplicit that the padding shall be part of the information > > > that is > > > included. Thus, implicitly the described procedure forbidds > > > padding. > > > Per RFC 3550 the padding is not part of the payload thus the need > > > for > > > being explicit about that the padding is to be included here. > > > > > > My suggestion is still that the following bullet: > > > > > > * Payload: The RTP payload of the original packet > > > > > > Is changes to be explicit that padding is to be included: > > > > > > "* Payload: The RTP payload (including > > > padding) of the original packet” > > > > > > Any other way that makes it explcit that the origianl packets > > > padding > > > is to be included is fine by me. But it does need to be explcit. > > > > > > Cheers > > > > > > Magnus > > > > > > On Fri, 2019-08-16 at 07:46 -0700, Suhas Nandakumar wrote: > > > > Hey Magnus > > > > > > > > Wondering if Richard's response answers your question? > > > > > > > > Thanks > > > > Suhas > > > > > > > > On Mon, Aug 5, 2019 at 7:48 AM Richard Barnes <rlb@ipv.sx> wrote: > > > > > Hey Magnus, > > > > > > > > > > Sorry, should have responded on Point 1. I think you're just > > > > > mistaken on that point. Padding is included within the inner > > > > > encryption. The double transform is an SRTP transform like any > > > > > other; outside of the SRTP stack, there is no "inner" or > > > "outer", > > > > > just the same old protect and unprotect. So padding works the > > > same > > > > > as it does with any other SRTP transform. > > > > > > > > > > Was there some text in the document that gave you the > > > impression > > > > > that padding was not included under the inner encryption? The > > > only > > > > > mention of padding I see in the document is in the figure in > > > > > Appendix A [1], where the padding is correctly shown to be > > > within > > > > > the inner encryption. Happy to clarify if you have some > > > > > suggestions for how. > > > > > > > > > > --Richard > > > > > > > > > > [1] > > > > > > > > https://tools.ietf.org/html/draft-ietf-perc-double-11#appendix-A > > > > > > > > > > On Mon, Aug 5, 2019 at 2:32 AM Magnus Westerlund < > > > > > magnus.westerlund@ericsson.com> wrote: > > > > > > Hi, > > > > > > > > > > > > Sorry, I missed when this update was submitted, thanks for > > > the > > > > > > reminder. > > > > > > > > > > > > The new version addresses most of my discuss, but missed to > > > do > > > > > > anything about point 1 below. > > > > > > > > > > > > Otherwise it appears to address my discuss points. How do you > > > > > > want to resolve it? > > > > > > > > > > > > Cheers > > > > > > > > > > > > Magnus Westerlund > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Cullen Jennings <fluffy@iii.ca> > > > > > > > Sent: den 17 maj 2019 20:34 > > > > > > > To: Magnus Westerlund <magnus.westerlund@ericsson.com> > > > > > > > Cc: The IESG <iesg@ietf.org>; perc-chairs@ietf.org; draft- > > > ietf- > > > > > > perc- > > > > > > > double@ietf.org; suhasietf@gmail.com; perc@ietf.org > > > > > > > Subject: Re: [Perc] Magnus Westerlund's Discuss on draft- > > > ietf- > > > > > > perc-double- > > > > > > > 10: (with DISCUSS and COMMENT) > > > > > > > > > > > > > > > > > > > > > > > 1. Section 5.1: > > > > > > > > > > > > > > > > To me it appears that one fundamental security flaw > > > exists in > > > > > > the > > > > > > > > definition of the inner encryption. That is the fact that > > > RTP > > > > > > padding > > > > > > > > is not included into the inner encrypted part. This > > > prevents > > > > > > the > > > > > > > > application of RTP padding to prevent the potential > > > privacy > > > > > > leakage > > > > > > > > that "Guidelines for the Use of Variable Bit Rate Audio > > > with > > > > > > Secure > > > > > > > > RTP" (RFC 6562) documents. To prevent this type of > > > > > > information leakage > > > > > > > > and other privacy preserving operations based on applying > > > RTP > > > > > > padding > > > > > > > > it would be necessary to include the RTP padding into the > > > > > > inner > > > > > > > > encrypted envelope. Appendix A figure indicates that is > > > the > > > > > > case, but the > > > > > > > process description in 5.1 is not matching that. > > > > > > > > > > > > > > > > > > > > > > So my read of 5.1 is that does this. Clearly we need to > > > make > > > > > > the text clear > > > > > > > that it does that - what part of the 5.1 makes you think > > > the > > > > > > padding is > > > > > > > stripped from the payload ? > > > > > > > > > > > > > > Perhaps to make it explicitly clear we should change > > > > > > > > > > > > > > "* Payload: The RTP payload of the original packet” > > > > > > > > > > > > > > to be > > > > > > > > > > > > > > "* Payload (including padding) The RTP payload (including > > > > > > passing) of the > > > > > > > original packet” > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Cheers > > Magnus Westerlund > > > ---------------------------------------------------------------------- > Network Architecture & Protocols, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > >
- [Perc] Magnus Westerlund's Discuss on draft-ietf-… Magnus Westerlund via Datatracker
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Cullen Jennings
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Magnus Westerlund
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Magnus Westerlund
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Richard Barnes
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Suhas Nandakumar
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Magnus Westerlund
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Richard Barnes
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Magnus Westerlund
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Richard Barnes