[tram] Stephen Farrell's No Objection on draft-ietf-tram-turn-third-party-authz-16: (with COMMENT)
"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Fri, 29 May 2015 11:19 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DD31A00DC; Fri, 29 May 2015 04:19:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjQhRKB8gdrO; Fri, 29 May 2015 04:19:03 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1151A00CF; Fri, 29 May 2015 04:19:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.3.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150529111903.28945.85802.idtracker@ietfa.amsl.com>
Date: Fri, 29 May 2015 04:19:03 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/tram/vR_4uLTRAv9PP40js3e4rli9dcU>
Cc: tram-chairs@ietf.org, tram@ietf.org, draft-ietf-tram-turn-third-party-authz@ietf.org, gonzalo.camarillo@ericsson.com, draft-ietf-tram-turn-third-party-authz.ad@ietf.org, draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org
Subject: [tram] Stephen Farrell's No Objection on draft-ietf-tram-turn-third-party-authz-16: (with COMMENT)
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2015 11:19:06 -0000
Stephen Farrell has entered the following ballot position for draft-ietf-tram-turn-third-party-authz-16: No Objection 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hiya, I've cleared my remaining discuss point which was to ask that the WG consider an alternative (and I think simpler) scheme based on signatures. Some of that discussion has happened so there's no reason to hold this up further. (I hope the discussion of simpler methods continues but that will depend on people being interested.) S OLD COMMENTS: - As some others have said before, this is still not an easy read and though better, could still do with more editorial work. - Why are 4.1.1 and 4.1.2 still just examples. You need one to be MTI or you won't get interop. Indeed 4.1.2 says you SHOULD do 4.1.1! Please just bite the bullet and clearly say that 4.1.1 is MTI. - 4.1.1, "HTTPS MUST be used for mutual authentication" is not a very clear way to say it. You mean that HTTPS MUST be used and that TLS with mutual authentication based on client certificates MUST be used. How does the WebRTC server know what CA the TURN server is going to use? That's another point of pre-arrangement that will be needed. - 4.1.1, I thought the web folks frowned upon specifying URI parameters like that. Shouldn't you at least use a .well-known URL or something so as to not get on someone eles's lawn? - 6.2, PATH_MTU is not the correct term. There are two paths involved, from WebRTC to browser and from browser to TURN server and MTUs need not be the same on those paths. OLD COMMENTS BELOW HERE, I DIDN'T CHECK THOSE. - 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] Stephen Farrell's No Objection on draft-ie… Stephen Farrell
- Re: [tram] Stephen Farrell's No Objection on draf… Tirumaleswar Reddy (tireddy)