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

["Ram Mohan R (rmohanr)" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 12 August 2015 8:35 am
To: Martin Thomson <[e-mail]<mailto:[e-mail]>>
Cc: "Tirumaleswar Reddy (tireddy)" <[e-mail]<mailto:[e-mail]>>, Stephen Farrell <[e-mail]<mailto:[e-mail]>>, The IESG <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT)

+1

Rest of the changes look good to me..

thanks,
Muthu

On Tue, Aug 11, 2015 at 10:35 PM, Martin Thomson <[e-mail]<mailto:[e-mail]>> wrote:
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)
<[e-mail]<mailto:[e-mail]>> 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]
>
>
>
> From: Muthu Arul Mozhi Perumal [mailto:[e-mail]<mailto:[e-mail]>]
> Sent: Thursday, August 06, 2015 10:27 AM
> To: Stephen Farrell
> Cc: The IESG; [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> 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 <[e-mail]<mailto:[e-mail]>>
> wrote:
>
> 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<http://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.
>
>
>
>
>
> [TR] Updated Consent definition.
>
>
>
> 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 ;)]
>
>
>
>
> (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?
>
>
>
> 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.
>
>
>
>
> (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?
>
>
>
> Yes, the mechanism has the same security properties within and outside the
> WebRTC sandboxing.
>
>
>
> 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.)
>
>
>
> 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.
>
>
> ----------------------------------------------------------------------
> 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.
>
>
>
> Agree, that should be "traffic".
>
>
>
>
> - 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?
>
>
>
> Consent is a new usage of STUN and is described in
> draft-ietf-rtcweb-security-arch, draft-ietf-rtcweb-security and in this
> document.
>
>
>
>
> - 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.
>
>
>
> 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..
>
>
>
> [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
>
>
>
>
> - 5.1, 3rd para: "Explicit consent to send is
> obtained..." is misleading. That is not a concept that
> 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
> needed?
>
>
>
> 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