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

[Magnus Westerlund <[e-mail]>]

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]
----------------------------------------------------------------------