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

>
> 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)
>>>
>>>
>>>
>>>
>>>