Re: Ban ICE-LITE? webRTC and Content Security Policy connect-src

That was my point as well.

On Fri, Jan 12, 2018 at 9:33 AM Taylor Brandstetter <deadbeef@google.com>
wrote:

> In Full ICE both endpoint need to send STUN requests (including
>> remote credentials) *before* media can be sent by any of them. Not
>> true in ICE Lite (obviously).
>>
>
> I don't think that's actually true. All it takes for an endpoint to begin
> sending media is to send a connectivity check and receive a response.
> That's what Chrome does at least, and I can't find anything in the standard
> that indicates otherwise.
>
> So, I don't see that there's any problem unique to ICE lite; this seems
> like a general issue.
>
> On Fri, Jan 12, 2018 at 8:40 AM, Peter Thatcher <pthatcher@google.com>
> wrote:
>
>> Sorry that's IP and port.
>>
>> So maybe domain-name-only remote ICE candidates with whitelisted domains
>> might work.   But I think that would mean ICE would then not work p2p, only
>> c2s.
>>
>> On Fri, Jan 12, 2018, 8:22 AM Peter Thatcher <pthatcher@google.com>
>> wrote:
>>
>>> As I pointed out on the other thread (why do we have 3 now?), I think
>>> any packets being sent by the browser where the JS can control the
>>> destination port is sufficient to convey information.
>>>
>>> On Fri, Jan 12, 2018, 5:48 AM Sergio Garcia Murillo <
>>> sergio.garcia.murillo@gmail.com> wrote:
>>>
>>>> Disclaimer: I did my ICE lite implementation 5 years ago, so I maybe
>>>> completely wrong.
>>>>
>>>> We are assuming that ICE lite is less secure that full ICE because in
>>>> full ICE you need to know the remote ufrag in order to create the request,
>>>> right?
>>>>
>>>> But that information will be available at the full ice endpoint as soon
>>>> as the first incoming stun binding request is received. So wouldn't this
>>>> mean that both full ice and ice lite are equally insecure?
>>>>
>>>> As Iñaki is pointing out what would be needed is to use the remote pwd
>>>> (which is not exchanged in stun request) in order to authenticate also the
>>>> remote peer. This is something I have never understood about ICE, why it
>>>> requires both ufrags to form the username, but only uses the local password
>>>> for fingerprinting (I assume is to speed up setup up times not having to
>>>> wait for remote peer info before starting ICE). Using local_pwd:remote_pwd
>>>> for fingerprinting would solve this issue altogether for both ice and
>>>> ice-lite.
>>>>
>>>> Best regards
>>>> Sergio
>>>>
>>>> On 12/01/2018 14:19, Harald Alvestrand wrote:
>>>>
>>>> To me, it sounds like we should ban ICE-LITE altogether.
>>>>
>>>> We've got a lot of security story resting on the idea that the ICE
>>>> request/response requires both ends to have seen the SDP.
>>>> If that isn't true for ICE-LITE, then ICE-LITE is not safe for WebRTC.
>>>>
>>>> On 01/12/2018 01:20 PM, Sergio Garcia Murillo wrote:
>>>>
>>>> Missed it, that will prevent it, right.
>>>>
>>>> On 12/01/2018 13:11, T H Panton wrote:
>>>>
>>>>
>>>> That's covered in my proposal:
>>>>
>>>> add a CSP turn-servers whitelist (to prevent leakage via the
>>>> credentials)
>>>>
>>>>
>>>>
>>>>
>>>>
>