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

[Muthu Arul Mozhi Perumal <[e-mail]>]

+1

Rest of the changes look good to me..

thanks,
Muthu

On Tue, Aug 11, 2015 at 10:35 PM, Martin Thomson <[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]> 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]]
> > Sent: Thursday, August 06, 2015 10:27 AM
> > To: Stephen Farrell
> > Cc: The IESG; [e-mail];
> > [e-mail];
> > [e-mail];
> > [e-mail]; [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]>
> > 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 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
>