Re: [tram] STUN Origin Security Considerations

Agreed.

Thanks for sending this, Brandon.  I will change this text and rev the
document, unless someone disagrees.

- Alan -

On Tue, Nov 18, 2014 at 9:08 PM, Oleg Moskalenko <mom040267@gmail.com>
wrote:

> That's a reasonable change.
>
> Oleg
>
> > On Nov 18, 2014, at 5:25 PM, Brandon Williams <
> brandon.williams@akamai.com> wrote:
> >
> > Hi all,
> >
> > In the meeting, I promised to follow up on this with a note to the list.
> >
> > Text in the current draft states the following:
> >
> >   The STUN ORIGIN attribute also has privacy implications in that the
> >   origin information is shared with a STUN or TURN server which
> >   otherwise might not know this information.  This information could be
> >   used to track usage of real-time communication services.  A STUN or
> >   TURN server will always know the public IP address of each user, but
> >   the ORIGIN attribute provides more information about which service or
> >   provider is being used.  The particular STUN and TURN servers used
> >   are selected by the real-time communications service provider (i.e.
> >   the web provider for WebRTC or the SIP or XMPP service provider).  In
> >   addition, they are usually also run by the same provider, or by a
> >   trusted partner, especially for TURN.  However, a service or provider
> >   using a public STUN server needs to recognize that the operator of
> >   the public STUN server will learn the identity of the service or
> >   provider through this extension.
> >
> > The last three sentences give the impression that the privacy concern
> does not apply to TURN servers, only to STUN servers, because TURN servers
> are more likely to be run by the application provider or a trusted partner
> of the application provider. This might not be true for auto-discovered,
> public, and other types of untrusted 3rd party TURN servers. The draft
> refers to "public STUN server" privacy implications, but I think the
> language could be broadened to cover all untrusted 3rd party relay servers.
> >
> > I propose the following minor modifications to the text, which I think
> clarify the intent. My changes are inclosed in [ ].
> >
> >   The particular STUN and TURN servers used are [usually] selected by
> >   the real-time communications provider ...
> >
> >   However, a service or provider using an [untrusted third party] STUN
> >   [or TURN] server needs to recognize that the operator of the
> >   [third party] STUN [or TURN] server will learn the identity of the
> >   service or provider through this extension.
> >
> > Does this seem reasonable?
> >
> > --Brandon
> >
> > --
> > Brandon Williams; Senior Principal Software Engineer
> > Emerging Products Engineering; Akamai Technologies Inc.
> >
> > _______________________________________________
> > tram mailing list
> > tram@ietf.org
> > https://www.ietf.org/mailman/listinfo/tram
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>