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

Great.  Brandon, I'm not sure if you still need me, but let's sync up next week :)

I will read the new draft pretty soon.

--  
Senior Architect, Akamai Technologies
IM: richsalz@jabber.at Twitter: RichSalz

> -----Original Message-----
> From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
> Sent: Friday, April 10, 2015 9:58 PM
> To: Williams, Brandon
> Cc: Salz, Rich; tram@ietf.org; tram-chairs@ietf.org; rlb@ipv.sx; Stephen
> Farrell (stephen.farrell@cs.tcd.ie)
> Subject: RE: [tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-
> party-authz-13: (with DISCUSS and COMMENT)
> 
> 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:tram-bounces@ietf.org] On Behalf Of Brandon
> > Williams
> > Sent: Saturday, April 11, 2015 1:28 AM
> > Cc: Salz, Rich; tram@ietf.org; tram-chairs@ietf.org
> > 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-aut
> > > hz
> > > /
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > --
> > > 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.
> >
> > _______________________________________________
> > tram mailing list
> > tram@ietf.org
> > https://www.ietf.org/mailman/listinfo/tram