Re: [tram] Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS)

[Simon Perreault <[e-mail]>]

Le 2015-05-12 12:41, Stephen Farrell a écrit :
>> In the case where a single entity controls the authentication databases
>> for all tenants of a single server, you're right. However, that
>> condition does not hold in general. That is, we really do need to
>> properly handle username collisions across realms.
> 
> Sorry, I'm really not getting that. It is not a name for
> a person, at least in WebRTC, right? It is some name
> agreed between the WebRTC JS code and the TURN server. And
> I'd hope it ought change frequently if it matters at all
> or else it'll be scraped from the JS (or debug tooling).

What you say is true for WebRTC. A REST API for obtaining ephemeral
usernames was even proposed:
https://tools.ietf.org/html/draft-uberti-behave-turn-rest-00

For SIP, however, usernames are not ephemeral, are not easily changed,
and, depending on what client provisioning allows, are often constrained
to be identical to the SIP username, while the realm is often
constrained to be identical to the SIP domain name. WebRTC front-ends to
SIP infrastructure could also have the same constraints.

>> I'd appreciate if we could recognize that there is a problem with
>> current practice, 
> 
> I believe I did that already.

Sorry, I understood your last email as suggesting that username hacks
made ORIGIN unnecessary.

>> 1) Are those concerns identical or different from those applying to,
>> e.g., the Host HTTP header, or the SNI TLS extension? If they're
>> different, how are they different?
> 
> They may or may not be different but doing something better also
> may or may not be more tractable. And the world has changed since
> e.g. SNI was defined. (There is also desire to hide SNI in the
> TLS 1.3 handshake if possible. We don't know if it will be possible
> or not but the desire is there and is real.)

I'm all for discussing something better, but at the moment I don't know
what that could be... Maybe it is obvious to security folks, but it is
not to me!

>> 2) Is there a proposal that could fix the privacy issue? So far I've
>> seen IESG members pointing out the issue, authors acknowledging the
>> issue, but no discussion of solutions.
> 
> From my POV, that is the discussion we are having and that is not
> yet done.

Ok, I'm happy to continue then! :)

Simon