Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-double-10: (with DISCUSS and COMMENT)

[Richard Barnes <[e-mail]>]

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 <
[e-mail]> 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 <[e-mail]> 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 <
> > > [e-mail]> 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 <[e-mail]>
> > > > > Sent: den 17 maj 2019 20:34
> > > > > To: Magnus Westerlund <[e-mail]>
> > > > > Cc: The IESG <[e-mail]>; [e-mail]; draft-ietf-
> > > > perc-
> > > > > [e-mail]; [e-mail]; [e-mail]
> > > > > 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  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>