Re: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT)

"Konda, Tirumaleswar Reddy" <> Thu, 11 July 2019 09:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6749D1202B1 for <>; Thu, 11 Jul 2019 02:07:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.999
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: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sHDwfsoJTQSf for <>; Thu, 11 Jul 2019 02:07:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 561011202B5 for <>; Thu, 11 Jul 2019 02:07:53 -0700 (PDT)
X-NAI-Header: Modified by McAfee Email Gateway (5500)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s_mcafee; t=1562835435; h=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=Lkhn7X2PtBiHoF4EgYlMghCcxDDArPcAhbNMJ+ DroYA=; b=MPrmV1IFfSWWRna98Db3nEW+mIgZ1zaGqfMPlx5f QbQKH++MzLjzyGn9RySL5ZN9ti9yumnr02tLQaCsLjdNMRQWcz K6idxt0cOKO2X5bJsYTnnTkPSzcMFKoYzT+/IUvkcbynoPuue6 IrK4gS5JzmCm7lLEpEJZ04Zq+B3WVKA=
Received: from ( []) (Using TLS) by with ESMTP id us-mta-110-17kfrR-JNNafawCIyn4vnA-1; Thu, 11 Jul 2019 05:07:48 -0400
Received: from ( []) by with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 3214_888e_01221dc1_c8f5_44e7_b93f_8b72c43753bd; Thu, 11 Jul 2019 02:57:15 -0600
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Jul 2019 03:07:32 -0600
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 11 Jul 2019 03:07:32 -0600
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Jul 2019 03:07:31 -0600
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Thu, 11 Jul 2019 09:07:29 +0000
Received: from ([fe80::570:2208:75c2:5f17]) by ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.019; Thu, 11 Jul 2019 09:07:29 +0000
From: "Konda, Tirumaleswar Reddy" <>
To: Roman Danyliw <>, The IESG <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT)
Thread-Index: AQHVN3Hb8rvCrm8yiE+tXfblQrByi6bE8P0w
Date: Thu, 11 Jul 2019 09:07:29 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
dlp-product: dlpe-windows
dlp-reaction: no-action
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6e09f599-d9a6-48af-374a-08d705df33b9
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB2152;
x-ms-traffictypediagnostic: DM5PR16MB2152:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0095BCF226
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(346002)(39860400002)(136003)(376002)(51914003)(13464003)(189003)(32952001)(199004)(71200400001)(14454004)(81166006)(2906002)(7736002)(74316002)(53936002)(476003)(54906003)(99286004)(305945005)(11346002)(316002)(478600001)(110136005)(66066001)(7696005)(6436002)(33656002)(8936002)(76116006)(8676002)(81156014)(486006)(229853002)(6246003)(14444005)(53546011)(6506007)(102836004)(26005)(76176011)(186003)(5024004)(256004)(80792005)(6116002)(5660300002)(68736007)(966005)(6306002)(446003)(55016002)(9686003)(66556008)(66574012)(66476007)(64756008)(66446008)(4326008)(71190400001)(52536014)(3846002)(86362001)(66946007)(25786009)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2152;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: uv5MPRgQohvsnOg15WHXtKALhEOks0Wq7cZPUra2gCfbVO0zHmGmAUDqe4xz4iT1rFR8ptdZ1xklggsuPtOGAIjKZL/zGaZXGjOoEVSathieiWmEqeERAnyMxPG7/+8XFo3luihMok0cadKSJyygyAxp8UE0q0OX4V4ojPTNlKWtmi3ymOnARGG7EgrcRXRuB7hbkxj2GYDD+KiJ90C+FCH4UCm1l3IvQTQh+ALy87hnDbhTX9n4fb5xE416VWffQC8fJw9hfdyNvqdC/oxmIxyXnRiQqIf83vvwKNyDKXKGuqmMHm9xxhiH+CvNFJ0zISQMtlEqZUcKLjxkwjoKSmPAL4fi1BpsVqa71hcdIN8IXhXGfFxx64eefcYFCz8+PIPwgNb5uB5eOVW3C9tSr0ik0SOvYAH8hTvXfJwlh/0=
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6e09f599-d9a6-48af-374a-08d705df33b9
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 09:07:29.8565 (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-Transport-CrossTenantHeadersStamped: DM5PR16MB2152
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.3
X-NAI-Spam-Version: : core <6587> : inlines <7117> : streams <1827027> : uri <2866268>
X-MC-Unique: 17kfrR-JNNafawCIyn4vnA-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <>
Subject: Re: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT)
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Jul 2019 09:07:58 -0000

Hi Roman,

Thanks for the review. Please see inline

> -----Original Message-----
> From: tram <> On Behalf Of Roman Danyliw via
> Datatracker
> Sent: Thursday, July 11, 2019 4:20 AM
> To: The IESG <>
> Cc:;;;
> Subject: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27: (with
> 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.
> Roman Danyliw has entered the following ballot position for
> draft-ietf-tram-turnbis-27: 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> (1) Section 12.1.6.  (Per the back-and-forth on Chris Wood’s SECDIR review –
> thank you Chris!) Per “Confidentiality is only a secondary concern, as TURN
> control messages do not include information that is particularly sensitive”,
> wouldn’t the USERNAME and REALM potentially be privacy sensitive?  If they
> aren’t sensitive in all cases (e.g., usernames might be ephemeral), this
> should be noted and cited.

Agreed, added the following paragraph:

   If the TURN client and server use the STUN Extension for Third-Party
   Authorization [RFC7635] (for example it is used in WebRTC), the
   username does not reveal the real user's identity, the USERNAME
   attribute carries an ephemeral and unique key identifier.  If the
   TURN client and server use the STUN long-term credential mechanism
   and the username reveals the real user's identity, the client needs
   to use (D)TLS transport between the client and the server or use the
   USERHASH attribute instead of the USERNAME attribute to anonynmize
   the username.

   If the TURN client and server use the STUN long-term credential
   mechanism and realm information is privacy sensitive, TURN can be run
   over (D)TLS.  As a reminder, STUN Extension for Third-Party
   Authorization does not use realm.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> (2) This draft relies on the draft-ietf-tram-stunbis’s STUN Password Algo
> Registry which has MD5 and SHA-256.  Section 16.1.1 of that draft already
> discusses the limitation of SHA-256 (which it might be useful to reference).
> Nevertheless, are there cases where MD5 should be used over SHA-256 if
> there is a choice?  Is there a reason not to recommend that implementations
> “SHOULD NOT use MD5”?

The only reason draft-ietf-tram-stunbis retained MD5 is for backward-compatibility (client using older version of STUN (RFC5389)). 

> (3) Section 5. Per “The client SHOULD include the SOFTWARE …” and “The
> client and the server MAY include the FINGERPRINT attribute …”, why is the
> sending of SOFTWARE not a “MAY” too?

This same behavior is defined in RFC5766 and turnbis does not modify the behavior, and to address the comment from Chris Wood (Secdir review) added the following line to Security Considerations section:

SOFTWARE 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. 

> (4) Section 5.  (Per the back-and-forth on Chris Wood’s SECDIR review)
> Recommend citing Section 6.3.1 of [draft-ietf-tram-stunbis] as source of 40
> second request buffer timeout


> (5) Section 21.4.  Per “It is RECOMMENDED that TURN servers not accept
> allocation or channel binding requests from addresses known to be
> tunneled”, I concur with the advice.  How would one recognize that the
> address is being tunneled?

By managing drop-list of tunnel IP addresses, it is the same technique used by several websites to block VPN access (see 


> _______________________________________________
> tram mailing list