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

[Stephen Farrell <[e-mail]>]

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:
> 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:draft-ietf-rtcweb-s
 t
[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
> 
>