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

[Stephen Farrell <[e-mail]>]

On 12/05/15 17:02, Simon Perreault wrote:
> Le 2015-05-11 21:14, Stephen Farrell a écrit :
>> There's also this issue. If user credentials can collide over >1
>> "realm" (where authentication realm means in the HTTP basic/digest
>> sense) then those are almost certainly human memorable (why else
>> could they collide with non-negligible probability?) and in the
>> case of STUN/TURN and, in particular, WebRTC, setting up to use
>> human memorable credentials is just basically broken given that
>> the humans aren't actually logging in to the STUN/TURN server.
> 
> 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).

> 
> That is a pain point that is currently being handled with a number of
> operational hacks. Clever username generation is one of them. It does
> work for some use cases, but not in general.
> 
> What you're describing is current practice, and we don't like it.
> 
> I'd appreciate if we could recognize that there is a problem with
> current practice, 

I believe I did that already.

> and actually discuss the merits of the ORIGIN
> solution. I understand the privacy concerns, but I don't get two things:
> 
> 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.)

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

S.

> 
> Simon
>