Re: ICE candidate search freezing and reuse of usernameFrag/password for components

Hi Emil,

I think I understand the fundamental confusion point.

ICE is used for consent and consent freshness. [BA] confirmed that it 
was not changed to Dtls. I think we both agree on this point.

However, it's my understanding that the browser generates the local 
ufrag:password and it's NOT changeable once created by the browser by 
the web application.See:

http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-09#section-5.3

Quote:
"The JS MUST NOT be permitted to control the local ufrag and password, 
though it of course knows it."


Even though in theory you can modify the SDP before setLocalDescription 
for WebRTC 1.0, you cannot modify the local ufrag:password which is 
assigned by the browser.

When I say "WebRTC ICE" that's what I mean. A normal application has 
control over their own ufrag:password. A web application has that value 
locked down and unmodifiable. There are special rules that browsers must 
adopt in relation to the web developer that are not normally restricted 
by stand alone applications.

-Robin



> Emil Ivov <mailto:emcho@jitsi.org>
> April 13, 2014 at 2:33 PM
> Hey Robin,
>
> On 13.04.14, 19:44, Robin Raymond wrote:
> [...]
>
> OK. In order for that to be true, you would need:
>
> a) a predictable unfreeze behaviour. I think that would mostly be 
> satisfied by using the order in which streams are created although we 
> may want to add a few helper methods.
>
> b) you need to be able to set ICE ufrags and passwords before ICE 
> processing starts and at any point during the lifetime of the 
> application.