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

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

Hi Stephen,

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

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


Regards,
Ram

-----Original Message-----
From: Stephen Farrell <[e-mail]>
Date: Thursday, 13 August 2015 6:30 pm
To: Cisco Employee <[e-mail]>, Muthu Arul Mozhi Perumal
<[e-mail]>, Martin Thomson <[e-mail]>
Cc: "Tirumaleswar Reddy (tireddy)" <[e-mail]>, The IESG
<[e-mail]>, "[e-mail]"
<[e-mail]>,
"[e-mail]" <[e-mail]>,
"[e-mail]"
<[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 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:draft-ietf-rtcw
>>[e-mail]>"
>><[e-mail]<mailto:draft-ietf-rtcw
>>[e-mail]>>,
>>"[e-mail]<mailto:[e-mail]>"
>><[e-mail]<mailto:[e-mail]>>,
>>"[e-mail]<mailto:draft-
>>[e-mail]>"
>><[e-mail]<mailto:draft-
>>[e-mail]>>,
>>"[e-mail]<mailto:draft-ietf-r
>>[e-mail]>"
>><[e-mail]<mailto:draft-ietf-r
>>tcweb-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:draft-ietf-rtcw
>>>[e-mail]>;
>>> [e-mail]<mailto:[e-mail]>;
>>> 
>>>[e-mail]<mailto:draft-
>>>[e-mail]>;
>>> 
>>>[e-mail]<mailto:draft-ietf-r
>>>[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-freshnes
>>>s/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> 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
>> 
>>