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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Hi Brandon,

Richard and we have already have discussed the comments further and resolved them, attached updated draft with diff.
Main changes

[1] Removed DKSPP
[2] Removed non-AEAD algorithms; using AEAD modes AES-GCM and aead-aes-cbc
[3] Updated the token format

-Tiru

> -----Original Message-----
> From: tram [mailto:[e-mail]] On Behalf Of Brandon Williams
> Sent: Saturday, April 11, 2015 1:28 AM
> Cc: Salz, Rich; [e-mail]; [e-mail]
> Subject: 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
> > [e-mail]
> > 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.
> 
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram