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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 5 Aug 2019 06:31:53 +0000

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 <[email-masked]>
> Sent: den 17 maj 2019 20:34
> To: Magnus Westerlund <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; draft-ietf-perc-
> [email-masked]; [email-masked]; [email-masked]
> 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”
> 
> 
> 
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 5 Aug 2019 10:47:33 -0400

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

---

From: Suhas Nandakumar <[email-masked]>
Date: Fri, 16 Aug 2019 07:46:08 -0700

Hey Magnus

   Wondering if Richard's response answers your question?

Thanks
Suhas

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 29 Aug 2019 09:50:01 +0000

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:
> > 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
> > 
-- 
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: [email-masked]
----------------------------------------------------------------------

---

From: Richard Barnes <[email-masked]>
Date: Thu, 29 Aug 2019 09:50:13 -0400

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 29 Aug 2019 14:19:20 +0000

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.
> 
> > > > > 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. 
> > > > > 
> > > > > > Cc: The IESG <[email-masked]>; [email-masked]; draft-
> > ietf-
> > > > > perc-
> > > > > > Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-
> > ietf-
> > > > > perc-double-
> > > > > > > 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
> > > > > > > and other privacy preserving operations based on applying
> > RTP
> > > > > padding
> > > > > > > encrypted envelope. Appendix A figure indicates that is
> > the
> > > > > case, but the
> > > > > > 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
-- 
Cheers

Magnus Westerlund

---

From: Richard Barnes <[email-masked]>
Date: Thu, 29 Aug 2019 10:29:43 -0400

draft-12 just posted.
https://datatracker.ietf.org/doc/draft-ietf-perc-double/