Subject: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 05 Aug 2015 15:38:37 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-rtcweb-stun-consent-freshness-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Apologies that these discuss points are maybe asking
fairly fundamental questions.  That could be that this
is really the first of the new security things required
by rtcweb to get to the IESG.  Or maybe I'm misreading
stuff here, if so, sorry;-)

(1) Why call this "consent?" That term is (ab)used in
many ways on the web, and adding another variation
without a definition that distinguishes this from "click
ok to my 200 page anti-privacy policy" or "remember that
example.com is allowed use my camera/mic" seems like a
terrible idea. I also don't see how this can ever be
something to which a normal person can "consent" (i.e.
consciously agree while fully understanding) so the term
is IMO very misleading, and will I fear be used to
mislead further.  (See also some of the comments below -
I do not think we ought be as fast and loose with this
aleady terribly badly used term.) To summarise: I'd love
if you did s/consent/anything-else/g but if not, please
define consent here in a way that clearly and
unambiguously distinguishes this usage from other abuses
of the term.

(2) WebRTC does not require STUN or TURN servers for
some calls, even if it does for many. Why is it ok to
require such a server be present in all calls (which I
think this means) espcially when that means exposing
additional meta-data (calling parties in a case where
the servers weren't needed and call duration in all
cases) to those servers when that is not always
necessary? 

(3) (end of p5) You have a MUST NOT here that is
depenedent on current browser implementations. Why is
that an IETF thing and not a W3C thing? But more
interestingly, can one securely use this protocol
without the kind of JS vs. browser sandboxing etc that's
needed in the web? If the answer is "no" then don't you
need to say that this protocol can only safely be used
for such implementations? (In section 2, which almost
but not quite says that.)

(4) Cleared.

(5) Cleared.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(Was discuss point#4) 
"Section 8: Where are these 96 bits defined? I think
this "requires..." statement needs a precise reference
to the place in some ICE/TURN/STUN RFC where it's
defined. (And I forget where that is, sorry:-) This
should be an easy fix."
Alissa gave me the reference [1] sothat's grand. It
might be an idea to make that clearer if it wasn't
just me missing it as I read, which is very possible;-)

[1] https://tools.ietf.org/html/rfc5389#section-6

- abstract: why is only sending "media" mentioned here?
What about data channels?  And the body of the document
in fact says this all applies to any non-ICE data and
not only media.

- intro: "initial consent to send by performing STUN" I
do not find the word consent in either rfc5245 or 3489,
but perhaps it is used somewhere else. Where?  And with
what meaning?

- section 4, 2nd last para - I think the conclusion is
bogus.  An implementation knows when the keying it's
using can not involve >1 (nominally operating) party.

- 5.1, 3rd para: "Explicit consent to send is
obtained..." is misleading. That is not a concept that
an implementation of STUN will embody. 

- 5.1, What is the "Note" about TCP for? Why is this
needed?

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Thu, 6 Aug 2015 10:26:42 +0530

Hi Stephen,

> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/

​The document already has a clear and unambiguous definition of the term,
IMHO: ​

​   Consent:  The mechanism of obtaining permission from the remote
      endpoint to send non-ICE traffic to a remote transport address.
      Consent is obtained using ICE.​

​Is that definition lacking something? ​I think finding an alter term would
be as hard as finding an alternate term for 'attack' as used in several
RFCs [attack being (ab)used in many contexts, including in heart attack ;)]

> cases) to those servers when that is not always

​That looks a misunderstanding. Consent freshness doesn't require such
server's to be present. Please point out to the text leading to the
misunderstanding.

> needed in the web?

​Yes, the mechanism has the same security properties within and outside the
WebRTC sandboxing.

> If the answer is "no" then don't you

​Section 2 doesn't say that. It only says WebRTC is the primary use case
for the mechanism at the moment and future use cases based on similar
sandboxing models can make use of it.

> (5) Cleared.

​Agree, that should be "traffic".

> but perhaps it is used somewhere else. Where?  And with

​Consent is a new usage of STUN and is described in
draft-ietf-rtcweb-security-arch, draft-ietf-rtcweb-security and in this
document.

> using can not involve >1 (nominally operating) party.

That paragraph is here:

​​   When Secure Real-time Transport Protocol (SRTP) is used, the
   following considerations are applicable.  SRTP is encrypted and
   authenticated with symmetric keys; that is, both sender and receiver
   know the keys.  With two party sessions, receipt of an authenticated
   packet from the single remote party is a strong assurance the packet
   came from that party.  However, when a session involves more than two
   parties, all of whom know each other's keys, any of those parties
   could have sent (or spoofed) the packet.  Such shared key
   distributions are possible with some MIKEY [RFC3830] modes, Security
   Descriptions [RFC4568], and EKT [I-D.ietf-avtcore-srtp-ekt].  Thus,
   in such shared keying distributions, receipt of an authenticated SRTP
   packet is not sufficient to verify consent.

​I'll defer it to someone who has more knowledge that me on shared key
distribution..

> an implementation of STUN will embody.

​As said earlier, consent is a new STUN usage. How would the following?

    An endpoint that implements this specification obtains and maintains
    consent to send by sending STUN binding request...

> - 5.1, What is the "Note" about TCP for? Why is this

​It is needed because WebRTC data traffic sent over TCP could get converted
to UDP by TURN servers. It is somewhat similar to why we need application
layer security when traffic is sent over IPSec. The later may not be
end-to-end.

Muthu

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 11 Aug 2015 14:31:25 +0000

Hi Stephen,

Updated draft to address your comments https://github.com/Draft-Mafia/Consentfreshness/compare/master...rmohanr-StephenConsentFreshness, Please have a look.
Also see inline [TR]

From: Muthu Arul Mozhi Perumal [mailto:[email-masked]]
Sent: Thursday, August 06, 2015 10:27 AM
To: Stephen Farrell
Cc: The IESG; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT)

Hi Stephen,

On Thu, Aug 6, 2015 at 4:08 AM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:
Stephen Farrell has entered the following ballot position for
draft-ietf-rtcweb-stun-consent-freshness-15: Discuss

example.com<http://example.com> is allowed use my camera/mic" seems like a

[TR] Updated Consent definition.

​The document already has a clear and unambiguous definition of the term, IMHO: ​

​Is that definition lacking something? ​I think finding an alter term would be as hard as finding an alternate term for 'attack' as used in several RFCs [attack being (ab)used in many contexts, including in heart attack ;)]

​That looks a misunderstanding. Consent freshness doesn't require such server's to be present. Please point out to the text leading to the misunderstanding.

​Yes, the mechanism has the same security properties within and outside the WebRTC sandboxing.

​Section 2 doesn't say that. It only says WebRTC is the primary use case for the mechanism at the moment and future use cases based on similar sandboxing models can make use of it.

(4) Cleared.

(5) Cleared.

(Was discuss point#4)

​Consent is a new usage of STUN and is described in draft-ietf-rtcweb-security-arch, draft-ietf-rtcweb-security and in this document.

That paragraph is here:

​I'll defer it to someone who has more knowledge that me on shared key distribution..

[TR] The idea behind the above paragraph is to use STUN consent checks in both two party and multi-party sessions. Consent checks uses
point-to-point keys so the endpoint knows if each remote peer in the call is willing to receive traffic or not.

-Tiru

​It is needed because WebRTC data traffic sent over TCP could get converted to UDP by TURN servers. It is somewhat similar to why we need application layer security when traffic is sent over IPSec. The later may not be end-to-end.

Muthu

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Aug 2015 10:05:13 -0700

You can strike all of this:

"The only human level "consent" here is that the application +
developer (e.g. WebRTC browser implementer) has programmed their +
application to adhere to this specification. The actual end users +
who are involved in the call have not consented to anything just +
because their browser uses this protocol."

On 11 August 2015 at 07:31, Tirumaleswar Reddy (tireddy)
<[email-masked]> wrote:
> Hi Stephen,
>
>
>
> Updated draft to address your comments
> https://github.com/Draft-Mafia/Consentfreshness/compare/master...rmohanr-StephenConsentFreshness,
> Please have a look.
>
> Also see inline [TR]
>
>
>
> Cc: The IESG; [email-masked];
> [email-masked];
> [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Stephen Farrell's Discuss on
> draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT)
>
>
>
> Hi Stephen,
>
>
>
> The document already has a clear and unambiguous definition of the term,
> IMHO:
>
>
>
>   Consent:  The mechanism of obtaining permission from the remote
>
>       Consent is obtained using ICE.
>
>
>
> Is that definition lacking something? I think finding an alter term would be
> as hard as finding an alternate term for 'attack' as used in several RFCs
> [attack being (ab)used in many contexts, including in heart attack ;)]
>
>
>
>
> That looks a misunderstanding. Consent freshness doesn't require such
> Yes, the mechanism has the same security properties within and outside the
> WebRTC sandboxing.
>
>
>
> Section 2 doesn't say that. It only says WebRTC is the primary use case for
> the mechanism at the moment and future use cases based on similar sandboxing
> models can make use of it.
>
>
>
>
> (4) Cleared.
>
> (5) Cleared.
>
>
> Agree, that should be "traffic".
>
>
>
>
> Consent is a new usage of STUN and is described in
>   When Secure Real-time Transport Protocol (SRTP) is used, the
>
> I'll defer it to someone who has more knowledge that me on shared key
> distribution..
>
>
>
> [TR] The idea behind the above paragraph is to use STUN consent checks in
> both two party and multi-party sessions. Consent checks uses
>
> As said earlier, consent is a new STUN usage. How would the following?
>
>
>
> It is needed because WebRTC data traffic sent over TCP could get converted

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Wed, 12 Aug 2015 08:35:18 +0530

+1

Rest of the changes look good to me..

thanks,
Muthu

On Tue, Aug 11, 2015 at 10:35 PM, Martin Thomson <[email-masked]>
wrote:

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > point-to-point keys so the endpoint knows if each remote peer in the
> call is
> > willing to receive traffic or not.
> >
> >
> >
> > -Tiru
> >
> >
> >
> >

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 12 Aug 2015 03:21:14 +0000

Ok.removed that para. Here is the updated diff.

https://github.com/Draft-Mafia/Consentfreshness/compare/master...rmohanr-StephenConsentFreshness

Thanks,
Ram

From: Muthu Arul Mozhi Perumal <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 12 August 2015 8:35 am
To: Martin Thomson <[email-masked]<mailto:[email-masked]>>
Cc: "Tirumaleswar Reddy (tireddy)" <[email-masked]<mailto:[email-masked]>>, Stephen Farrell <[email-masked]<mailto:[email-masked]>>, The IESG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT)

+1

thanks,
Muthu

On Tue, Aug 11, 2015 at 10:35 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
You can strike all of this:

On 11 August 2015 at 07:31, Tirumaleswar Reddy (tireddy)
<[email-masked]<mailto:[email-masked]>> wrote:
> From: Muthu Arul Mozhi Perumal [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: The IESG; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 13 Aug 2015 14:13:30 +0000

Hi Stephen,

Thanks for your review. Here is the new revision with the below diffs
published.

Regards,
Ram

-----Original Message-----
From: Stephen Farrell <[email-masked]>
Date: Thursday, 13 August 2015 6:30 pm
To: Cisco Employee <[email-masked]>, Muthu Arul Mozhi Perumal
<[email-masked]>, Martin Thomson <[email-masked]>
Cc: "Tirumaleswar Reddy (tireddy)" <[email-masked]>, The IESG
<[email-masked]>, "[email-masked]"
<[email-masked]>,
"[email-masked]" <[email-masked]>,
"[email-masked]"
<[email-masked]>,
"[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: Stephen Farrell's Discuss on
draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT)

>
>Hi Folks,
>
>Sorry for being slow, but I've now had another read of the draft
>and if you submit those changes I'll be fine to clear.
>
>Thanks,
>S.
>
>
>On 12/08/15 04:21, Ram Mohan R (rmohanr) wrote:
>> From: Muthu Arul Mozhi Perumal
>><[email-masked]<mailto:[email-masked]>>
>> To: Martin Thomson
>><[email-masked]<mailto:[email-masked]>>
>> Cc: "Tirumaleswar Reddy (tireddy)"
>><[email-masked]<mailto:[email-masked]>>, Stephen Farrell
>><[email-masked]<mailto:[email-masked]>>, The IESG
>><[email-masked]<mailto:[email-masked]>>,
>>"[email-masked]<mailto:draft-ietf-rtcw
>>[email-masked]>"
>><[email-masked]<mailto:draft-ietf-rtcw
>>[email-masked]>>,
>>"[email-masked]<mailto:[email-masked]>"
>><[email-masked]<mailto:[email-masked]>>,
>>"[email-masked]<mailto:draft-
>>[email-masked]>"
>><[email-masked]<mailto:draft-
>>[email-masked]>>,
>>"[email-masked]<mailto:draft-ietf-r
>>[email-masked]>"
>><[email-masked]<mailto:draft-ietf-r
>>tcweb-s
> t
>[email-masked]>>,
>"[email-masked]<mailto:[email-masked]>"
><[email-masked]<mailto:[email-masked]>>
>> On Tue, Aug 11, 2015 at 10:35 PM, Martin Thomson
>><[email-masked]<mailto:[email-masked]>> wrote:
>>> From: Muthu Arul Mozhi Perumal
>>>[mailto:[email-masked]<mailto:[email-masked]>]
>>> Cc: The IESG; 
>>>[email-masked]<mailto:draft-ietf-rtcw
>>>[email-masked]>;
>>>[email-masked]<mailto:draft-
>>>[email-masked]>;
>>> 
>>>[email-masked]<mailto:draft-ietf-r
>>>[email-masked]>;
>>>[email-masked]<mailto:[email-masked]>
>>> On Thu, Aug 6, 2015 at 4:08 AM, Stephen Farrell
>>><[email-masked]<mailto:[email-masked]>>
>>> wrote:
>>>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Aug 2015 14:00:50 +0100

Hi Folks,

Thanks,
S.

On 12/08/15 04:21, Ram Mohan R (rmohanr) wrote:
> Cc: "Tirumaleswar Reddy (tireddy)" <[email-masked]<mailto:[email-masked]>>, Stephen Farrell <[email-masked]<mailto:[email-masked]>>, The IESG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:draft-ietf-rtcweb-s
 t
[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>