[tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-party-authz-13: (with DISCUSS and COMMENT)

["Stephen Farrell" <[e-mail]>]

Stephen Farrell has entered the following ballot position for
draft-ietf-tram-turn-third-party-authz-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


Edited discuss ballot after chats around Dallas.

(1) Please fix the crypto as per Richard's discuss. (I think
the plan here is for Rich Salz to help with that, which 
I'm confident will work out ok.)

(2) Please consider whether a signature based 
scheme that does not require pre-shared keys between
the TURN and (in particular) WebRTC server could
be useful to support. (Either in this document or 
elsewhere.) There should be use cases where that
offers sufficient accountability for use of TURN and
it ought allow some deployments that are less easy
with this kind of pre-shared keys approach. The 
DISCUSS here is to check if the WG want to take
that approach, either now or later.

(3) I think the plan is to take out some of the options
that are not needed so as make interop more likely.
Please do so. (I think we discussed taking out the
DKSPP stuff at least, but the more options we can
get rid of, the better).


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- COMMENTS below are unchanged since before Dallas.
We can look over then as we go.

- I really think this would benefit from some wider review
and I don't think it's ready as-is.

- I agree with Richard's discuss points.

- intro: "impossible in web applications" isn't really
true in principle, but impossible in WebRTC as it uses JS
is true. 

- Assuming the AS that can authorize the user shares a
secret with the STUN server chosen by the WebRTC server
seems very brittle. Why would that be true in general?

- 4.1.1: Hmmm. How many people use KeyProv I wonder?

- 4.1.2 - which "two servers"? WebRTC can have more
servers than that.

- 4.1.2 - now we're using TLS mutual auth? And how does
the TLS client know which CA to use that'll work with the
TLS server here? I don't think that'll scale will it?

- 4.1.3 - this looks like what the WG/authors really want,
would that be a fair statement?

- 9: Figure 2 should be way up at the top of the document
and not here

- 9: Why 5 seconds?