Subject: [rtcweb] Adopting draft-muthu-behave-consent-freshness?

From: Magnus Westerlund <[email-masked]>
Date: Mon, 9 Sep 2013 10:36:56 +0200

WG,

This is a call for WG adoption of STUN Usage for Consent Freshness
(draft-muthu-behave-consent-freshness-04). This document defines a STUN
usage for consent freshness. As this requires no protocol extensions we
as intended users can define this usage in our WG. Such work also
matches our charter. The draft-ietf-rtcweb-security-arch-07 is
normatively dependent on this STUN usage.

Document:
https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/

WG, please indicate your support or issues with adopting this document
as WG item with a proposed milestone:

Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication
as proposed standard.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Simon Perreault <[email-masked]>
Date: Mon, 09 Sep 2013 11:24:30 +0200

> Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication

I have commented multiple times on this doc. I support its adoption now.

Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 09 Sep 2013 12:00:26 +0200

I support adoption as a working group document.

On 09/09/2013 10:36 AM, Magnus Westerlund wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Sep 2013 12:20:16 +0000

Hi,

I don't object adoption, but a question for clarification.

The draft says:

   "While a WebRTC browser could verify whether the peer continues to
   send SRTCP reports before sending traffic to the peer, the usage of
   SRTCP together with Security Descriptions [RFC4568] requires exposing
   the media keys to the JavaScript and renders SRTCP unsuitable for
   consent freshness."

Now, as we have decided to not use SDES, I guess that can be removed.

But, based on that, I'd just like to verify whether there is still a need for the draft :)

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: 9. syyskuuta 2013 11:37
To: [email-masked]
Subject: [rtcweb] Adopting draft-muthu-behave-consent-freshness?

WG,

This is a call for WG adoption of STUN Usage for Consent Freshness (draft-muthu-behave-consent-freshness-04). This document defines a STUN usage for consent freshness. As this requires no protocol extensions we as intended users can define this usage in our WG. Such work also matches our charter. The draft-ietf-rtcweb-security-arch-07 is normatively dependent on this STUN usage.

Document:

WG, please indicate your support or issues with adopting this document as WG item with a proposed milestone:

Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication as proposed standard.

Cheers

Magnus Westerlund

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 09 Sep 2013 14:27:36 +0200

Changing the subject line to make life simpler for those who count the 
respondents :-)

> But, based on that, I'd just like to verify whether there is still a need for the draft :)

Personal opinion: I think SRTCP is still unsuitable for consent 
freshness. One reason (apart from any aspect that deals with security, 
on which I don't want to comment) is that if one sets up a connection 
with only a data channel, there will be no SSRCs to send SRTCP on.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Sep 2013 12:44:22 +0000

Hi,

And, from a security perspective (the backward compatibility is a separate issue) the requirement to integrity protect the STUN binding requests are not affected by the SDES decision?

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: 9. syyskuuta 2013 15:28
To: [email-masked]
Subject: [rtcweb] Consent freshness in the light of no-SDES (Re: Adopting draft-muthu-behave-consent-freshness?)

Changing the subject line to make life simpler for those who count the respondents :-)

> But, based on that, I'd just like to verify whether there is still a 

Personal opinion: I think SRTCP is still unsuitable for consent freshness. One reason (apart from any aspect that deals with security, on which I don't want to comment) is that if one sets up a connection with only a data channel, there will be no SSRCs to send SRTCP on.

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Mon, 09 Sep 2013 15:38:36 +0200

> as WG item with a proposed milestone:

I support adopting this document.

/alfred

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 9 Sep 2013 08:29:06 -0700

+1

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 9 Sep 2013 08:45:55 -0700

Christer said: 
"Now, as we have decided to not use SDES, I guess that can be removed."
[BA] Actually, I believe that a sentence or two describing why the needs of consent freshness are not met by mechanisms such as SRTCP is worth keeping, and possibly should even be expanded upon.  One reason is that we also have the "circuit breakers" mechanism which *does* rely (in part) on SRTCP.   
Christer said: 
"But, based on that, I'd just like to verify whether there is still a need for the draft :)"
[BA] I do think that the draft is still necessary, even without SDES/SRTP.   The usage of ICE for consent seems to me to be less susceptible to a variety of issues than a dependency on SRTCP might be. 
However, I am concerned about the interaction between circuit breakers and consent freshness.  At IETF 87, we heard that the circuit breakers mechanism could fire even when the overall loss rate was quite low, due to burst losses.  That shouldn't be true of consent, since loss of consent requires up to 30 consecutive losses over a 15 second period.  However, it would appear to me that the current circuit breakers algorithms will cause media sending to be curtailed prior to loss of consent in many cases.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 9 Sep 2013 17:54:41 +0000

I support adoption of this draft as a WG item for the given milestone.

Cheers,
Charles

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Sep 2013 11:04:27 -0700

On 9 September 2013 05:27, Harald Alvestrand <[email-masked]> wrote:
> Personal opinion: I think SRTCP is still unsuitable for consent freshness.
> One reason (apart from any aspect that deals with security, on which I don't
> want to comment) is that if one sets up a connection with only a data
> channel, there will be no SSRCs to send SRTCP on.

This is my opinion too.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Sep 2013 11:06:55 -0700

> And, from a security perspective (the backward compatibility is a separate issue) the requirement to integrity protect the STUN binding requests are not affected by the SDES decision?

Integrity protection prevents an on-path attacker who is ignorant of
ICE credentials from artificially extending consent.  That's a fairly
restricted set.

The whole SDES interaction with consent is pretty weak, if you ask me.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Sep 2013 11:19:50 -0700

> as WG item with a proposed milestone:

I think that we should adopt this draft, then fix it.  The proposed
algorithm is still quite confusingly specified.  It also unnecessarily
conflates liveness testing with consent.

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Mon, 9 Sep 2013 19:01:41 +0000

+1

---

From: Victor Pascual <[email-masked]>
Date: Tue, 10 Sep 2013 05:57:37 +0200

+1

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 10 Sep 2013 00:45:35 -0700

+1

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 10 Sep 2013 07:16:05 -0700

+1

On Tue, Sep 10, 2013 at 12:45 AM, Timothy B. Terriberry <
[email-masked]> wrote:

> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: "Mishra, Sanjay" <[email-masked]>
Date: Tue, 10 Sep 2013 15:08:26 -0400

Muthu et al -- 

In the abstract, second paragraph, the text states "how" a WebRTC browser can verify peer consent and as I read through the rest of the document I also understood "why" this is needed. So, just a knit pick, it may be clear to the reader if the statement also includes why within the body of the Abstract.

One minor typo in section 7. Please change "in-intended" to "un-intended".

Thanks
Sanjay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Monday, September 09, 2013 4:37 AM
To: [email-masked]
Subject: [rtcweb] Adopting draft-muthu-behave-consent-freshness?

WG,

Document:

Cheers

Magnus Westerlund

---

From: Dan Wing <[email-masked]>
Date: Tue, 10 Sep 2013 13:33:29 -0700

> However, I am concerned about the interaction between circuit breakers and consent freshness.  At IETF 87, we heard that the circuit breakers mechanism could fire even when the overall loss rate wa…

Yes, consent needs to avoid the same pitfalls that were explained for circuit breakers.  

(For others that might be interested, the AVT presentation describing the research on circuit breakers is at http://www.ietf.org/proceedings/87/slides/slides-87-avtcore-2.pdf.)

-d

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 11 Sep 2013 03:51:28 +0000

|In the abstract, second paragraph, the text states "how" a WebRTC 
|browser can verify peer consent and as I read through the rest of 
|the document I also understood "why" this is needed. So, just a knit
|pick, it may be clear to the reader if the statement also includes 
|why within the body of the Abstract.

The "why" part is mentioned in the first paragraph of the abstract:
   Verification of peer consent before sending traffic is necessary in
   WebRTC deployments to ensure that a malicious JavaScript cannot use
   the browser as a platform for launching attacks.

Are you suggesting expanding this? The abstract needs to be concise, however.

|One minor typo in section 7. Please change "in-intended" to "un-intended".

Will fix it.

Thanks for the review..

Muthu 

|-----Original Message-----
|From: Mishra, Sanjay [mailto:[email-masked]]
|Sent: Wednesday, September 11, 2013 12:38 AM
|To: Muthu Arul Mozhi Perumal (mperumal); Dan Wing (dwing); Ram Mohan R (rmohanr); Tirumaleswar Reddy
|(tireddy)
|Cc: [email-masked]
|Subject: RE: [rtcweb] Adopting draft-muthu-behave-consent-freshness?
|
|Muthu et al --
|
|
|In the abstract, second paragraph, the text states "how" a WebRTC browser can verify peer consent and
|as I read through the rest of the document I also understood "why" this is needed. So, just a knit
|pick, it may be clear to the reader if the statement also includes why within the body of the
|Abstract.
|
|One minor typo in section 7. Please change "in-intended" to "un-intended".
|
|Thanks
|Sanjay
|
|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
|Sent: Monday, September 09, 2013 4:37 AM
|To: [email-masked]
|Subject: [rtcweb] Adopting draft-muthu-behave-consent-freshness?
|
|WG,
|
|This is a call for WG adoption of STUN Usage for Consent Freshness (draft-muthu-behave-consent-
|freshness-04). This document defines a STUN usage for consent freshness. As this requires no protocol
|extensions we as intended users can define this usage in our WG. Such work also matches our charter.
|The draft-ietf-rtcweb-security-arch-07 is normatively dependent on this STUN usage.
|
|Document:
|https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/
|
|WG, please indicate your support or issues with adopting this document as WG item with a proposed
|milestone:
|
|Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication as proposed standard.
|
|Cheers
|
|Magnus Westerlund
|
|----------------------------------------------------------------------
|Multimedia Technologies, Ericsson Research EAB/TVM
|----------------------------------------------------------------------
|Ericsson AB                | Phone  +46 10 7148287
|Färögatan 6                | Mobile +46 73 0949079
|SE-164 80 Stockholm, Sweden| mailto: [email-masked]
|----------------------------------------------------------------------
|
|_______________________________________________
|rtcweb mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Mishra, Sanjay" <[email-masked]>
Date: Wed, 11 Sep 2013 08:53:03 -0400

> Are you suggesting expanding this? The abstract needs to be concise, however.

I agree the first paragraph states the premise and that is good, however, the second paragraph which lays out the purpose of this document, and since the purpose is both how and why, the second paragraph could state something like this:

"This document describes both how and why a webRTC browser can and must verify peer consent to continue sending traffic and detect connection failure."

Thanks
Sanjay

-----Original Message-----
From: Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]] 
Sent: Tuesday, September 10, 2013 11:51 PM
To: Mishra, Sanjay; Dan Wing (dwing); Ram Mohan R (rmohanr); Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: RE: [rtcweb] Adopting draft-muthu-behave-consent-freshness?

|In the abstract, second paragraph, the text states "how" a WebRTC 
|browser can verify peer consent and as I read through the rest of the 
|document I also understood "why" this is needed. So, just a knit pick, 
|it may be clear to the reader if the statement also includes why within 
|the body of the Abstract.

Will fix it.

Thanks for the review..

Muthu 

|-----Original Message-----
|From: Mishra, Sanjay [mailto:[email-masked]]
|Sent: Wednesday, September 11, 2013 12:38 AM
|To: Muthu Arul Mozhi Perumal (mperumal); Dan Wing (dwing); Ram Mohan R 
|(rmohanr); Tirumaleswar Reddy
|(tireddy)
|Cc: [email-masked]
|Subject: RE: [rtcweb] Adopting draft-muthu-behave-consent-freshness?
|
|Muthu et al --
|
|
|In the abstract, second paragraph, the text states "how" a WebRTC 
|browser can verify peer consent and as I read through the rest of the 
|document I also understood "why" this is needed. So, just a knit pick, 
|it may be clear to the reader if the statement also includes why within the body of the Abstract.
|
|One minor typo in section 7. Please change "in-intended" to "un-intended".
|
|Thanks
|Sanjay
|
|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On 
|Behalf Of Magnus Westerlund
|Sent: Monday, September 09, 2013 4:37 AM
|To: [email-masked]
|Subject: [rtcweb] Adopting draft-muthu-behave-consent-freshness?
|
|WG,
|
|This is a call for WG adoption of STUN Usage for Consent Freshness 
|(draft-muthu-behave-consent- freshness-04). This document defines a 
|STUN usage for consent freshness. As this requires no protocol extensions we as intended users can define this usage in our WG. Such work also matches our charter.
|The draft-ietf-rtcweb-security-arch-07 is normatively dependent on this STUN usage.
|
|Document:
|https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/
|
|WG, please indicate your support or issues with adopting this document 
|as WG item with a proposed
|milestone:
|
|Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication as proposed standard.
|
|Cheers
|
|Magnus Westerlund
|
|----------------------------------------------------------------------
|Multimedia Technologies, Ericsson Research EAB/TVM
|----------------------------------------------------------------------
|Ericsson AB                | Phone  +46 10 7148287
|Färögatan 6                | Mobile +46 73 0949079
|SE-164 80 Stockholm, Sweden| mailto: [email-masked]
|----------------------------------------------------------------------
|
|_______________________________________________
|rtcweb mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Lijing (Jessie, Huawei)" <[email-masked]>
Date: Fri, 13 Sep 2013 02:08:35 +0000

Hi all,

As a newcomer to RTCWEB, I have some doubts after I have read the draft. 

1. in "4.  Solution Overview", may be it would be better to clarify when to send a STUN Binding Request(in the middle of a media session or before sending traffic, during sending traffic or only during silence periods) and which side to send the request(controlling agent or both sides)? During the session, there are RTP/RTCP media streams which can keep the NAT mapping and confirm the connectivity state of the media plane. Before the session, we can use the ICE connectivity checks. 
So according to my understanding, the STUN Binding Request should only be sent during the silence periods. A media connectivity check with a request and a response during a session, is this the main idea of this document?

2. in " 7.  Security Considerations", there are the following words. 
  "Once that connection to the remote
   peer has been established with ICE, the consent to continue sending
   traffic does not benefit from re-asserting that same username and
   password, so long as the senders and receiver's IP addresses remain
   the same (as they usually do)."

   As when one agent receives STUN Binding Request, unlike the processing of STUN Binding Indication message, it have to do more processes to send the Response message, I am not sure whether it is appreciate not to authenticate the source and respond directly. Is it more likely to receive malicious attacks?

Neglect my words, if my understandings are wrong.

Best regards,

Jessie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Monday, September 09, 2013 4:37 PM
To: [email-masked]
Subject: [rtcweb] Adopting draft-muthu-behave-consent-freshness?

WG,

Document:

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 17 Sep 2013 10:46:18 +0200

WG,

More than a week since this call was issued has passed. There has been
strong support for adopting this WG item and the draft as a starting
point. I will therefore request approval for the milestone from the AD.

As pointed out there is clearly some issues in the draft that needs to
be addressed. These will now be the WG concern. So please continue
review and provide proposals for improving the document.

Cheers

Magnus Westerlund
WG Chair

-- 

Magnus Westerlund