Problems with Session Traversal Utilities for NAT (STUN) Long-Term Authentication for Traversal Using Relays around NAT (TURN)
draft-ietf-tram-auth-problems-05

I have no objection to the publication of this document.

Here are two editorial notes for you to consider.

---

The use of upper case "MUST" in a pseudo-quote from RFC5766 seems
unnecessary.

---

A little work on abbreviations is needed...

I don't believe TURN or STUN are "well-known abbreviations" according to
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt so you
should expand them in:
- document title
- Abstract
- main document on first use
  (you do this for TURN, but note that the referenced 5766 uses a 
  different expansion from the one you use!)

Is there some inconsistency between WebRTC and RTCWEB?

ICE should be expanded on first use. You have expanded it two paragraphs
later.

I am interested to see the responses to a few of Stephen's questions and don't have any more to add.  Thanks for your work on the draft.

A bunch of comments, but all non-blocking or really less.
That is, feel free to ignore these unless you think they make
the doc better. I'd rather this got out there and we moved on
to solutions more quickly compared to waiting for the perfect
version of this.

section 1: 1st bullet - where is it defined how to use a TURN
server for privacy? And I don't actually see how that'd work,
unless the caller trusts the TURN server to do it. Might well
be my ignorance of TURN though.

section 4, point 7: malicious JS is not required, any browser
can view the source, including the STUN pwd.

section 4: A possible 8th point is that a STUN/TURN server
for WebRTC could have to work for many many browsers at which
point assuming any secret known to all is a secret is just
silly.

section 4: Another possible new point is that STUN auth was
meant for the WebRTC equivalent of the browser but in fact
the web site (via the site's JS) is in control and hence it
really ought be the web site that authenticates to the STUN
server and not (supposedly) the WebRTC browser.

section 4: Yet another - if a WebRTC server sets "per-user"
STUN passwords via some form of co-ordination with some
STUN/TURN servers, then that will assist in tracking
individual user behaviour and so may be a privacy concern.

section 4 (or 1): Current STUN/TURN auth essentially forces
some centralisation into WebRTC where that ought not be
needed. For example, models based on a leap-of-faith could
actually be good enough to prevent widespread abuse of
resources.