Re: [tram] Secdir last call review of draft-ietf-tram-turnbis-27

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Fri, 12 July 2019 13:01 UTC

Return-Path: <tirumaleswarreddy_konda@mcafee.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6292120045 for <tram@ietfa.amsl.com>; Fri, 12 Jul 2019 06:01:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.com
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 OwyEqUDDs1eO for <tram@ietfa.amsl.com>; Fri, 12 Jul 2019 06:01:29 -0700 (PDT)
Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD961200C5 for <tram@ietf.org>; Fri, 12 Jul 2019 06:01:29 -0700 (PDT)
X-NAI-Header: Modified by McAfee Email Gateway (5500)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562935841; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=loBSUN30EadwAboQoVxqgjpMSNyPGG78/RC94I vKELo=; b=EBlhtQ1hZ1sUvxmd0vvaIODPlu32ES+hGdGOkM14 cZf48qGBR6vcD3Ax5M25ZTrII1lt1v0AjyjaGoCOSQ0Lj0OrMY JY7Fvbc1NcFqT/mk8ac7vafRpCpa+yWKDWfVxYO59HtOPQvwGz hozm+yvW1LkbGq2Q1yKt9JbQUUG2g6s=
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-70-VQsFFgDgPT2XiOObIEL_6w-1; Fri, 12 Jul 2019 09:01:18 -0400
Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 2f15_6c24_326978ac_545f_48e8_ada6_573df227ceb2; Fri, 12 Jul 2019 06:50:40 -0600
Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 12 Jul 2019 07:01:15 -0600
Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 12 Jul 2019 07:01:15 -0600
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 12 Jul 2019 07:01:11 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K4v8yQDlb8VeVhGs+J7RQ/pu+2BGHPMHDhfP1ChdKYVLhMRlt3uJ5cpNLPxJULbmQP9Z3ZXEHufRouo0H2sa8EpZiMBtkRnjOZKLjBW5AgUFvZCDGoZZx52XNgw1VWi2nkDLvSeUiPXvpuPZYrizX+ov4q1Jn1r8aq5gRjQyesYAlRdN8lSe8EQhczXcmdvIWPUPAwiYay/b2rNeXrFWrTK+FJdg9SedvN1OwOVdstJUg4EuKIX+0fCcBHO7HeNZZcjxLL3pQ+zu+eHy9rAGL/lbtTP9IWEOnrI7bwK4teC4Yigm/Sa3PknZgZWIfaa0m62xtYnRQKgUZhAc4RnTmw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=loBSUN30EadwAboQoVxqgjpMSNyPGG78/RC94IvKELo=; b=oFW6x0x6FRtApaAPtcYJqhYqJ2RBe8FRyZgEBSEl/Nep5juBQFIpnWrvPMWMsIDv0Mm8PMprheQXawJ4YLLzX4yLBqFS7jyLpf8x98mes9ZmlKQukMdRj0xWCWFENUbndjWh7hoqzVx/kUgDKcWMCH05y4vGsE8yJVQ2WN6SEhjLnV99LzQfc5Zlt6zgAttXYocTA7a/jTyIvQX7J3TDO7OL7ql2+Qy8wZHZSTQ9oayHikWTNm2iF88NhS5Vp0e1WxHonYurmSBZlEEWtOhLUDrzQFDOhXmca50Jl5QSU4DeutNx9xVpX5XShr/uilGxXCSuVydqRdKtono7rg9IrA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none
Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1801.namprd16.prod.outlook.com (10.174.176.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Fri, 12 Jul 2019 13:01:10 +0000
Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.019; Fri, 12 Jul 2019 13:01:10 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Christopher Wood <caw@heapingbits.net>, Benjamin Kaduk <kaduk@mit.edu>
CC: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-tram-turnbis.all@ietf.org" <draft-ietf-tram-turnbis.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "tram@ietf.org" <tram@ietf.org>
Thread-Topic: [tram] Secdir last call review of draft-ietf-tram-turnbis-27
Thread-Index: AQHVNQMAJeymFhPVnEO1ky4wx5pqrabAcMBwgAJPmICAAKIlAIACozsAgAC0umA=
Date: Fri, 12 Jul 2019 13:01:09 +0000
Message-ID: <DM5PR16MB1705248936E8E282776832BDEAF20@DM5PR16MB1705.namprd16.prod.outlook.com>
References: <156253133809.549.13521510978566357744@ietfa.amsl.com> <DM5PR16MB17057A838828AE1DFD33702AEAF60@DM5PR16MB1705.namprd16.prod.outlook.com> <20190709203044.GD24351@kduck.mit.edu> <DM5PR16MB17055A8B96B74CD7E978591FEAF00@DM5PR16MB1705.namprd16.prod.outlook.com> <8ba1f7d3-d286-46df-9c13-383340bbf7b5@www.fastmail.com>
In-Reply-To: <8ba1f7d3-d286-46df-9c13-383340bbf7b5@www.fastmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.3.0.16
dlp-reaction: no-action
x-originating-ip: [49.37.206.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: db3655d5-e213-4cb1-3014-08d706c902cc
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1801;
x-ms-traffictypediagnostic: DM5PR16MB1801:
x-ms-exchange-purlcount: 10
x-microsoft-antispam-prvs: <DM5PR16MB18014B391BFFFF978A74CDEDEAF20@DM5PR16MB1801.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00963989E5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(366004)(136003)(396003)(39860400002)(346002)(51914003)(13464003)(189003)(52014003)(199004)(32952001)(52536014)(102836004)(316002)(6246003)(6116002)(6506007)(66556008)(53546011)(186003)(64756008)(26005)(7696005)(99286004)(66946007)(66446008)(30864003)(76176011)(110136005)(3846002)(76116006)(66476007)(54906003)(86362001)(5660300002)(66066001)(2906002)(9686003)(11346002)(966005)(446003)(71190400001)(53936002)(81166006)(6436002)(80792005)(81156014)(6306002)(55016002)(476003)(305945005)(486006)(74316002)(229853002)(7736002)(71200400001)(8936002)(256004)(33656002)(14454004)(4326008)(68736007)(5024004)(14444005)(478600001)(8676002)(25786009)(2171002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1801; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: hZUhB3pSEX5RS8k7gGUvl9GYRSxwh3+hGaMNxkq6qlQkxeiuuPP2IOeYsZ8Usrte9QhFL89OWNEGKuOzj1KZ4facZdcd/tO+h9N5j67s5RyC1BziCy3yMn62+UKRltYny4kLSLnuo9INLilpQ8fQfwXh+n6OoUDrW/jij6oOp5KgyUCvK5dPwE013ZjRm4AUkLqgREkq1qR+sRhkrfMNObcWroDcn6PLUNsWCMJoSdzruUx06zxacxFqkCKQp2qXXHqHAtIaWpIPqzUsJ6cvz+igI1a7WFCt/rqhurc0AXIga7WGX+95uXc6APrXlPZQ87+aCaqRoDizvoRvRojfEjhvovDLcW1GFzEGjuJ8Y/g8SD9VoWdI7V5hVC3nSIdAWk0obd3tEZ83kxb+Lt2ZfCzo8+ZnFxXF+craWXjrlrk=
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: db3655d5-e213-4cb1-3014-08d706c902cc
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2019 13:01:10.0132 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1801
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.1
X-NAI-Spam-Version: 2.3.0.9418 : core <6589> : inlines <7118> : streams <1827138> : uri <2866735>
X-MC-Unique: VQsFFgDgPT2XiOObIEL_6w-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/UA7Aj9crJOz4yuxxDQ8NzC13OYY>
Subject: Re: [tram] Secdir last call review of draft-ietf-tram-turnbis-27
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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, 12 Jul 2019 13:01:34 -0000

Hi Chris,

Please see inline 

> -----Original Message-----
> From: Christopher Wood <caw@heapingbits.net>;
> Sent: Friday, July 12, 2019 3:58 AM
> To: Konda, Tirumaleswar Reddy
> <TirumaleswarReddy_Konda@McAfee.com>;; Benjamin Kaduk
> <kaduk@mit.edu>;
> Cc: secdir@ietf.org; draft-ietf-tram-turnbis.all@ietf.org; ietf@ietf.org;
> tram@ietf.org
> Subject: Re: [tram] Secdir last call review of draft-ietf-tram-turnbis-27
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> Hi Tiru,
> 
> On Wed, Jul 10, 2019, at 5:41 AM, Konda, Tirumaleswar Reddy wrote:
> > Hi Ben,
> >
> > Thanks for the review. Please see inline.
> >
> > > -----Original Message-----
> > > From: Benjamin Kaduk <kaduk@mit.edu>;
> > > Sent: Wednesday, July 10, 2019 2:01 AM
> > > To: Konda, Tirumaleswar Reddy
> <TirumaleswarReddy_Konda@McAfee.com>;
> > > Cc: Christopher Wood <caw@heapingbits.net>;; secdir@ietf.org;
> > > draft-ietf- tram-turnbis.all@ietf.org; ietf@ietf.org; tram@ietf.org
> > > Subject: Re: [tram] Secdir last call review of
> > > draft-ietf-tram-turnbis-27
> > >
> > > This email originated from outside of the organization. Do not click
> > > links or open attachments unless you recognize the sender and know
> > > the content is safe.
> > >
> > > Chris, thanks for the review.  Some more questions/comments inline
> > > as I prepare to ballot on this document...
> > >
> > > On Mon, Jul 08, 2019 at 02:18:26PM +0000, Konda, Tirumaleswar Reddy
> wrote:
> > > > Hi Christopher,
> > > >
> > > > Thanks for the detailed review. Please see inline
> > > >
> > > > > -----Original Message-----
> > > > > From: tram <tram-bounces@ietf.org>; On Behalf Of Christopher
> Wood
> > > > > via Datatracker
> > > > > Sent: Monday, July 8, 2019 1:59 AM
> > > > > To: secdir@ietf.org
> > > > > Cc: draft-ietf-tram-turnbis.all@ietf.org; ietf@ietf.org;
> > > > > tram@ietf.org
> > > > > Subject: [tram] Secdir last call review of
> > > > > draft-ietf-tram-turnbis-27
> > > > >
> > > > > This email originated from outside of the organization. Do not
> > > > > click links or open attachments unless you recognize the sender
> > > > > and know the content is safe.
> > > > >
> > > > > Reviewer: Christopher Wood
> > > > > Review result: Has Nits
> > > > >
> > > > > I have reviewed this document as part of the security
> > > > > directorate's ongoing effort to review all IETF documents being
> > > > > processed by the IESG. These comments were written primarily for
> > > > > the benefit of the security area directors.
> > > > > Document editors and WG chairs should treat these comments just
> > > > > like any other last call comments.
> > > > >
> > > > > The summary of the review is: Ready with nits
> > > > >
> > > > > Summary:
> > > > >
> > > > > In general, the document is well written and clearly founded in
> > > > > operational experience. The security considerations are
> > > > > thorough, providing examples where necessary to highlight
> > > > > important problem areas. It draws a clear line between issues
> > > > > best addressed by applications outside of TURN, and provides
> > > > > sufficient detail for those issues in scope. My comments and
> > > > > questions are, hopefully, mostly
> > > nits.
> > > > >
> > > > > General comments:
> > > > >
> > > > > - TURN server authentication in the case of (D)TLS is
> > > > > underspecified. Are servers assumed to have WebPKI certificates,
> > > > > OOB-trusted raw public keys, or something else? Is there a
> > > > > preferred
> > > form of authentication?
> > > > > Relatedly, in
> > > > > Section 3.2, how do clients authenticate the server?
> > > >
> > > > Server certificate validation is discussed in
> > > > https://tools.ietf.org/html/draft-
> > > ietf-tram-stunbis-21#section-6.2.3.  I have modified the text as follows:
> > > >
> > > > If (D)TLS transport is used between the TURN client and the TURN
> > > > server, the cipher suites, server certificate validation and
> > > > authentication of TURN server are discussed in Section 6.2.3 of
> > > > [I-D.ietf-tram-stunbis]
> > >
> > > That helps, but it would still be nice to give some indication of
> > > what certificate
> > > PKI(s) are expected to be used.  Is anything other than the Web PKI
> > > under consideration ?
> >
> > No. Please see
> > https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-6.2.3,
> > It discusses to verify the certificate path and identity of the server.
> 
> Perhaps it would be good to explicitly say this in the document?

I added the following line:

If (D)TLS transport is used between the TURN client and the TURN 
server, the cipher suites, server certificate validation and 
authentication of TURN server are discussed in Section 6.2.3 of 
[I-D.ietf-tram-stunbis].

> 
> >
> > >
> > > > >- Section 3.7: Could
> > > > > TURN servers not chunk data from stream-oriented transports (TCP
> > > > >or
> > > > >TLS)  to a preferred MTU size before relaying to peers?
> > > > > Specifically, there are likely
> > > > > some cases wherein the server could deal with the client data
> > > > >messages  larger than the recommended 500B limit. On that point,
> > > > >should servers even  accept data larger than this recommended size ?
> > > > >-
> > > >
> > > > Please see
> > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-27#section-15
> > > > for TCP-to-UDP relay. If the PMTU is not known, and on legacy or
> > > > otherwise unusual networks,
> > > > 500 byte limit for application data is recommended.
> > > >
> > > > > Section 3.9: There may be
> > > > > cases where the TLS connection post TCP connection establishment
> > > > > fails. It would therefore seems prudent to not declare victory
> > > > > for one connection over the other until TLS connects, too. -
> > > >
> > > > Agreed, Eric (as part of ISEG review) suggested to simplify the
> > > > text. I have
> > > updated the text as follows:
> > > >
> > > >    o  For TCP or TLS-over-TCP, the results of the Happy Eyeballs
> > > >       procedure [RFC8305] are used by the TURN client for sending its
> > > >       TURN messages to the server.
> > >
> > > Is the editor's copy available for viewing somewhere?  It would be
> > > good to see this (and other changes) in context.
> >
> > Yes, Please see https://github.com/tireddy2/TURNbis
> 
> Thanks!
> 
> >
> > >
> > > > > Section 3 could benefit from a
> > > > > subsection on replays and the nonce role. In particular, as
> > > > > later discussed in the security considerations, some of these
> > > > > attacks are not new to TURN and should therefore be dealt with
> > > > > by the application protocol (SRTP). This section might also
> > > > > describe nonce rotation policies with more specificity, as this
> > > > > is underspecified in the
> > > document.
> > > >
> > > > It is discussed in Section 5 in the specification, the server
> > > > should expire the
> > > nonce at least once every hour during the lifetime of the allocation.
> > > >
> > > > >- Section 3 could also benefit from  discussion about cleartext
> > > > >versus encryption transports between clients and  servers.
> > > >
> > > > It is discussed in
> > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-
> > > 27#section-21.1.6.
> > >
> > > There's not much discussion about potential information  leakage via
> > > (e.g.) USERNAME/USERHASH, and really just a claim that the peer
> > > address is the "primary protocol content".
> 
> +1 to Ben's concern, which echoes my own.
> 
> > Agreed, added the following paragraph :
> >
> > If the TURN client and server use the STUN Extension for Third-Party
> > Authorization [RFC7635], the username does not reveal the real user's
> > identity, the USERNAME attribute carries an ephemeral and unique key
> > identifier, and the key identifier can change per call.
> > If the TURN client and server use the STUN long-term credential
> > mechanism and the username reveals the real user's identity, the
> > client need to either use (D)TLS transport between the client and the
> > server or use the USERHASH attribute instead of the USERNAME attribute
> > to anonynmize the username.
> 
> This is an improvement -- thanks! Should use of (D)TLS be mandated
> ("MUST" instead of "need to") when long-term credentials are used?

I think you mean (D)TLS or USERHASH must be used, updated the line as follows:

If the TURN client and server use the STUN long-term credential mechanism and the username reveals the real user's identity, the client MUST either use the USERHASH attribute instead of the USERNAME attribute to anonynmize the username or use 
(D)TLS transport between the client and the server.

> 
> > > > > Encrypting the nonce, username, realm, etc., among other things,
> > > > > has obvious benefits. - Why are SOFTWARE and FINGERPRINT
> > > > > attributes recommended?  It seems like clients should be
> > > > > discouraged from sending these if anything, especially if not
> > > > > used to make allocation decisions on the server.
> > > >
> > > > Username may not be the user identity, Please see
> > > https://tools.ietf.org/html/rfc7635), It could be an ephemeral and
> > > unique key identifier. Further, username can be anonymized (please
> > > see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-14.4).
> > > > SOFTWARE and FINGERPRINT attributes are defined in the STUN
> > > specification, see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21.
> 
> I realize they're defined elsewhere. My concern was that this draft seems to
> encourage sending them when perhaps that's not needed, i.e., as is the case
> for the SOFTWARE attribute.

This "SHOULD" to send SOFTWARE attribute is defined in RFC5766 (As you may know, TURN is used in the field for several years) and turnbis does not modify the behavior for backward compatibility. The use of FINGERPRINT is not mandatory, the draft says the TURN client and server may include the FINGERPRINT attribute.  

> 
> > >
> > > These mechanisms  are partial mitigations but can still be
> > > susceptible to cross- connection correlation attacks.
> >
> > The use of FINGERPRINT is not mandatory, the TURN client and server
> > may include the FINGERPRINT attribute.  Note that ICE
> > (https://tools.ietf.org/html/rfc8445) mandates the use of FINGERPRINT
> > attribute. Added the following line for SOFTWARE attribute (TURNbis is
> > using the same behavior defined in RFC5766 to use SOFTWARE attribute)  :
> >
> > SOFWATE attribute can reveal the specific software version of the TURN
> > client and server to eavesdropper and it might possibly allow attacks
> > against vulnerable software that is known to contain security holes.
> > If it is important to prevent an eavesdropper from learning the
> > software version, TURN can be run over (D)TLS.
> 
> I'd replace "holes" with "vulnerabilities," and rewrite

Done.

> 
>    "If  it is important to prevent an eavesdropper from learning the software
> version, TURN can be run over (D)TLS."
> 
> as follows:
> 
> "TURN SHOULD be run over (D)TLS to prevent leaking the SOFTWARE
> attribute in clear text."

We want to avoid double encryption of application data, and SOFTWARE attribute has been sent in clear text all these years in the field, and no attack has been detected based on SOFTWARE field. I can revise the text as follows:
If the software version is known to contain security vulnerabilities, TURN SHOULD be run over (D)TLS to prevent leaking the SOFTWARE attribute in clear text.

> 
> > > > - Section 5: When servers receive data that exceeds an
> > > > allocation’s
> > > > > bandwidth quota, servers silently discard this data. This means
> > > > > there’s no allocation-based flow control mechanism between
> > > > > client and server beyond what’s provided by the transport protocol,
> right?
> > > >
> > > > Yes, UDP does not include a congestion control mechanism.
> 
> Right -- it might be good to mention this explicitly.

Updated.

> 
> > > > > This seems fine, though
> > > > > perhaps some discussion of why this design decision was made
> > > > > would be helpful. For example, I could imagine explicit signals
> > > > > from servers to clients that indicate server state would reveal
> > > > > information about other allocations on the server, which might
> > > > > be problematic. -
> > > >
> > > > The errors 486 (Allocation Quota Exceeded) or 508 (Insufficient
> > > > Capacity)
> > > do not reveal information of which other users are using the TURN server.
> 
> Perhaps not which other *users* are using the TURN server, correct. It may
> leak other information though, and drawing HTTP 503 response code analogy
> would be helpful.

Added the following line:
Note that the error code values 486 and 508 indicate to a eavesdropper and the client that several other users are using the server at this time, similar to that of the HTTP error response code 503, but does not reveal any information about the users using the TURN server.

Cheers,
-Tiru

> 
> > > At least the latter seems to give some indication that many other
> > > users are using the server at the  time (so that it's overloaded),
> > > though not information about *which* users that is.
> >
> > Yes, similar to 503 HTTP error response.
> >
> > >
> > > > > Section 7.2 suggests that
> > > > > servers can redirect client allocation requests to other servers.
> > > > > Can this create a loop, wherein two TURN servers redirect to one
> another?
> > > >
> > > > The client detect and stop the loop, it is similar to HTTP redirection.
> > >
> > > Where is this specified?
> >
> > It is specified in the last paragraph of
> > https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-10
> 
> Aha -- I missed that. Thanks!
> 
> Best,
> Chris