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

Hi all,

I will try to touch base with Rich Salz re: Richard's crypto comments 
next week in order to help drive getting his feedback.

--Brandon

On 04/10/2015 03:38 PM, Stephen Farrell wrote:
> 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?
>
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.