Re: [secdir] [tram] Secdir last call review of draft-ietf-tram-turnbis-27
"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Sat, 13 July 2019 06:36 UTC
Return-Path: <tirumaleswarreddy_konda@mcafee.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D333E120019 for <secdir@ietfa.amsl.com>; Fri, 12 Jul 2019 23:36:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level:
X-Spam-Status: No, score=-4 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] 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 dqN7kMq_xoHf for <secdir@ietfa.amsl.com>; Fri, 12 Jul 2019 23:36:03 -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 2D3D112008F for <secdir@ietf.org>; Fri, 12 Jul 2019 23:36:02 -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=1562999012; 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=HdHIBLUvxV9nBwHx9il9njs1v1KMliJoOD6aSk JnyRs=; b=oK29Fhqcgr7+eWrAvP7JXj6Xdpufr7qxmGOMT3OQ O07Hgg6OBBry7NizRcLGR5insLZKiBGb97pHE0VBoTEJ1bf5hM Y5bWSXHeKuwYRDT90YJ1i6u2f2VjkG1QxTp2XicOKhnxkL7mVh /hvVEAy0sjZ2mP3esZVyWp6i6XtpnkU=
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-64-f9efpBi6MVS1ut7ZN3N54A-1; Sat, 13 Jul 2019 02:34:11 -0400
Received: from DNVEXAPP1N06.corpzone.internalzone.com (DNVEXAPP1N06.corpzone.internalzone.com [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6c32_3f4c_f84f959d_71c3_41ce_bc1b_9db7e5c5de58; Sat, 13 Jul 2019 00:23:30 -0600
Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 13 Jul 2019 00:34:07 -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; Sat, 13 Jul 2019 00:34:06 -0600
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 13 Jul 2019 00:34:06 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EXw85X756G8NCkL76pr70n1cFh5ej4kQcFFUXS0d+L5ZOunudwJn09OS8dY6HG6A8KF4mo+HEcsKtItzTEBK7bZJQB0i0qQ5KhwzhWCzKrB+hFn2bO/QngtTmJr2DNkiZLw/LYc4Vr8jVYn53JXBkZKdnkjccuQcj4URuAEJNDLL/I807vFN4vji1MLIeuoKIm9bhMDbTOUFGDoDIt47WDvju/fZAv9uM+DYwKfkhB0ys/CenumcyoI/t0d1nh+noIsX2RDvHkIiI5JyQc2L5NI1LyWYe+WRltS6xVB9oSgO7i2P2qYYJV8be65eLOwnMEUuTAKY31nK3DgecpIKUw==
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=HdHIBLUvxV9nBwHx9il9njs1v1KMliJoOD6aSkJnyRs=; b=EIN+TWcgw3lYylIyNMR5x2FV8XUq+L5k4Vvqp0bgKbv4JwqdCKvR0LgLFeNq/qvXyGr9mgiuenbP7G/qzkZuB6zAHJ1mG9njfI57Nj2hYeO4E+1XlkfD7Y2dlM21LYpY1sfsLd5W1TAvz+5XwhIcIwPZULMu8XcgUWWZZ6heWDUnTQa/IiJXscPRRZxMZ3NuCRt8hRPagjpjHzR2E1dCFsPfO+GbVnd/5eey0CWZADmIis9fRDImaVk3Tz2pW3IkoSf13lzzpp502CcoqCKH+tRl36O9Rp9q/7b36nuZsb2DMybKsCV0Paq+TfW3BUUTjdlDseJ0+sQoLsThW4oPpg==
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 DM5SPR00MB110.namprd16.prod.outlook.com (10.174.247.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Sat, 13 Jul 2019 06:34:03 +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.022; Sat, 13 Jul 2019 06:34:03 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: Christopher Wood <caw@heapingbits.net>, "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: AQHVNQMAJeymFhPVnEO1ky4wx5pqrabAcMBwgAJPmICAAKIlAIAEbccAgABJSTA=
Date: Sat, 13 Jul 2019 06:34:03 +0000
Message-ID: <DM5PR16MB1705CA7A7BA6D7F7706B1D5AEACD0@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> <20190713014901.GQ16418@mit.edu>
In-Reply-To: <20190713014901.GQ16418@mit.edu>
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: 283f07b6-b761-4696-6c1b-08d7075c1936
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DM5SPR00MB110;
x-ms-traffictypediagnostic: DM5SPR00MB110:
x-ms-exchange-purlcount: 10
x-microsoft-antispam-prvs: <DM5SPR00MB110C04B379C32E91D158AF0EACD0@DM5SPR00MB110.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00979FCB3A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(346002)(396003)(136003)(39860400002)(13464003)(32952001)(199004)(189003)(51914003)(6246003)(55016002)(7736002)(2171002)(6306002)(9686003)(305945005)(66066001)(81156014)(81166006)(5024004)(53936002)(53546011)(74316002)(33656002)(256004)(14444005)(54906003)(30864003)(478600001)(3846002)(476003)(486006)(102836004)(6506007)(25786009)(99286004)(7696005)(8936002)(11346002)(6116002)(76176011)(2906002)(5660300002)(6436002)(68736007)(66946007)(229853002)(316002)(86362001)(52536014)(8676002)(186003)(80792005)(4326008)(446003)(6916009)(966005)(66556008)(66446008)(76116006)(71200400001)(71190400001)(64756008)(66476007)(14454004)(26005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5SPR00MB110; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: fP6KleNox3jXAqkgTODruftalyd/njDKzBh9tSWHLoUWm+Hbu92F5BcyBQ704zg3R58t+5e748r51E60Esq4O3khvmhh40+hqbH9PlPmSGz9U94Zpj3o6TiWD43wUYGTk5QWmLo/IDWIuuLXwevOg8WZdnPlGt6xLGGZ0l21KN4t5LrS7Q0FFX9GwgYkhVbiRyLKyTMEt8F75LVF/4UDOHDzn2vGJBlU1RJw4PDOt0miRLEOe0f3w5EJmdAqxuBRuQrl3GpF5ESs6oaUS5PgKmTxs2wTi9C5WrqHpnN9rpPnYEtgMP4hEhIlh8krO8uwlpBL5JWWDryd9WNgNbe/RdSAYRudPcWx0/gSfC1O1gJvzTuXsArUMij7SJ/oHHfl4bu6kRPjx59xDQCF1z4uDBx1dhZ7FkEsTzLFfhw44n4=
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 283f07b6-b761-4696-6c1b-08d7075c1936
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2019 06:34:03.5795 (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: DM5SPR00MB110
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 <7119> : streams <1827208> : uri <2867009>
X-MC-Unique: f9efpBi6MVS1ut7ZN3N54A-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/secdir/txmpe9_5IeO0mPL720YnOelwRHI>
Subject: Re: [secdir] [tram] Secdir last call review of draft-ietf-tram-turnbis-27
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Jul 2019 06:36:05 -0000
Hi Ben, Please see inline > -----Original Message----- > From: Benjamin Kaduk <kaduk@mit.edu> > Sent: Saturday, July 13, 2019 7:19 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. > > Hi Tiru, > > Thanks for all the updates, including further downthread with Chris. > Just a couple notes inline... > > On Wed, Jul 10, 2019 at 12:40:37PM +0000, 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. > > > > > > > > > >- 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 > > > > > > > > > > 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". > > > > 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. > > > > > > > > > > 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. > > > > > > 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. > > The later suggestion was: > > % 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. > > I think some of the concern is over the risk of so-called "zero-day" > exploits, where the attacker knows of a version-specific flaw but the > defenders do not (and have zero days notice to protect against it). Such a > concern would suggest to avoid sending SOFTWARE over enencrypted > transport regardless of the state of known vulnerabilities, but in the end it is > a matter of local policy. Agreed, fixing and releasing a patch will take some time and meanwhile the policy can be modified to use temporarily use (D)TLS. I can add the following text: If zero-day vulnerabilities are detected in the software version, the endpoint policy can be modified to mandate the use of (D)TLS till the patch is in place to fix the flaw. > > > > > > > > > > > - 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. > > > > > > > > > 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. > > > > > > 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 > > > > <snip> > > If the client has been redirected to a server to which it has already > > sent this request within the last five minutes, it MUST ignore the > > redirection and consider the transaction to have failed. This > > prevents infinite ping-ponging between servers in case of redirection > > loops. > > </snip> > > Thanks for the pointer; as you saw in my ballot position I was quite pressed > for time this week and only was able to look at the diff. No problem, thanks for help. Cheers, -Tiru > > -Ben
- [secdir] Secdir last call review of draft-ietf-tr… Christopher Wood via Datatracker
- Re: [secdir] [tram] Secdir last call review of dr… Konda, Tirumaleswar Reddy
- Re: [secdir] [tram] Secdir last call review of dr… Benjamin Kaduk
- Re: [secdir] [tram] Secdir last call review of dr… Konda, Tirumaleswar Reddy
- Re: [secdir] [tram] Secdir last call review of dr… Christopher Wood
- Re: [secdir] [tram] Secdir last call review of dr… Konda, Tirumaleswar Reddy
- Re: [secdir] [tram] Secdir last call review of dr… Benjamin Kaduk
- Re: [secdir] [tram] Secdir last call review of dr… Konda, Tirumaleswar Reddy