Subject: [tram] STUN Origin Security Considerations

From: Brandon Williams <[email-masked]>
Date: Tue, 18 Nov 2014 20:25:01 -0500

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.

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 18 Nov 2014 19:08:13 -0800

That's a reasonable change.

Oleg

> On Nov 18, 2014, at 5:25 PM, Brandon Williams <[email-masked]> wrote:
> 
> Hi all,
> 
> 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 [ ].
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Alan Johnston <[email-masked]>
Date: Tue, 18 Nov 2014 21:29:40 -0600

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 <[email-masked]>
wrote:

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

---

From: Simon Perreault <[email-masked]>
Date: Fri, 28 Nov 2014 09:09:01 -0500

> document, unless someone disagrees.

Good! We'll start WGLC when the new rev is posted.

Simon