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

Roman Danyliw <rdd@cert.org> Sun, 21 July 2019 16:11 UTC

Return-Path: <rdd@cert.org>
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 AC634120180; Sun, 21 Jul 2019 09:11:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 DxyruxwSFx9S; Sun, 21 Jul 2019 09:11:04 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9773120199; Sun, 21 Jul 2019 09:11:04 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6LGB0Qv019501; Sun, 21 Jul 2019 12:11:00 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x6LGB0Qv019501
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1563725460; bh=X6jT72Hl870TR1+uSPU5lR//XelgsFp7rT4R8OPSEHY=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=JiR/6K7ZGIiBZTeYwZv8Sw+7vFPNgyhH8UouNzNXFSQ3dQsu0EBM7HZEnsQVwgd+b QyKjMc2EF/Fz3bYKEo3zYsEjJ4x5NQ1V9Aj9mKq8z5tmFJHp6DRrIHwsCJEIOCjz45 CYc+K5ihgZVJXqXumGU8Z/qko22XbOrRvD+qv8Kg=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6LGAv7S037963; Sun, 21 Jul 2019 12:10:57 -0400
Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0439.000; Sun, 21 Jul 2019 12:10:56 -0400
From: Roman Danyliw <rdd@cert.org>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>, The IESG <iesg@ietf.org>
CC: "tram-chairs@ietf.org" <tram-chairs@ietf.org>, "draft-ietf-tram-turnbis@ietf.org" <draft-ietf-tram-turnbis@ietf.org>, "tram@ietf.org" <tram@ietf.org>, "brandon.williams@akamai.com" <brandon.williams@akamai.com>
Thread-Topic: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT)
Thread-Index: AQHVN3HNOcpHzxrvaEaIlo9IaIQd0abFZEuAgADMpZCAAMcpgIAIE8eAgAY3KfA=
Date: Sun, 21 Jul 2019 16:10:55 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33DE345@marchand>
References: <156279899179.15443.1948808943181719878.idtracker@ietfa.amsl.com> <DM5PR16MB17055D5E91DFEF395F011404EAF30@DM5PR16MB1705.namprd16.prod.outlook.com> <359EC4B99E040048A7131E0F4E113AFC01B33CE08D@marchand> <DM5PR16MB170599B4382A90A390A3C2CAEAF20@DM5PR16MB1705.namprd16.prod.outlook.com> <DM5PR16MB1705F52E71B5552FB66AAD6BEAC90@DM5PR16MB1705.namprd16.prod.outlook.com>
In-Reply-To: <DM5PR16MB1705F52E71B5552FB66AAD6BEAC90@DM5PR16MB1705.namprd16.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/NsUIRWCdpaWcAOvpruT1pO5oByQ>
Subject: Re: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT)
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: Sun, 21 Jul 2019 16:11:13 -0000

Hi Tiru!

This proposed -28 addresses all of my concerns.  Thank you for the update.

Roman

> -----Original Message-----
> From: Konda, Tirumaleswar Reddy
> [mailto:TirumaleswarReddy_Konda@mcafee.com]
> Sent: Wednesday, July 17, 2019 8:34 AM
> To: Roman Danyliw <rdd@cert.org>;; The IESG <iesg@ietf.org>;
> Cc: tram-chairs@ietf.org; draft-ietf-tram-turnbis@ietf.org; tram@ietf.org;
> brandon.williams@akamai.com
> Subject: RE: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27:
> (with DISCUSS and COMMENT)
> 
> Hi Roman,
> 
> I have updated the draft to address your Discuss and comments (see
> https://github.com/tireddy2/TURNbis/blob/master/Diff%20%20draft-ietf-
> tram-turnbis-27.txt%20-%20draft-ietf-tram-turnbis-28.pdf).
> Please have a look.
> 
> Cheers,
> -Tiru
> 
> > -----Original Message-----
> > From: Konda, Tirumaleswar Reddy
> > Sent: Friday, July 12, 2019 2:43 PM
> > To: Roman Danyliw <rdd@cert.org>;; The IESG <iesg@ietf.org>;
> > Cc: tram-chairs@ietf.org; draft-ietf-tram-turnbis@ietf.org;
> > tram@ietf.org; brandon.williams@akamai.com
> > Subject: RE: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27:
> > (with DISCUSS and COMMENT)
> >
> > Hi Roman,
> >
> > Please see inline
> >
> > > -----Original Message-----
> > > From: Roman Danyliw <rdd@cert.org>;
> > > Sent: Friday, July 12, 2019 7:00 AM
> > > To: Konda, Tirumaleswar Reddy
> > > <TirumaleswarReddy_Konda@McAfee.com>;; The IESG <iesg@ietf.org>;
> > > Cc: tram-chairs@ietf.org; draft-ietf-tram-turnbis@ietf.org;
> > > tram@ietf.org; brandon.williams@akamai.com
> > > Subject: RE: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-
> 27:
> > > (with DISCUSS and COMMENT)
> > >
> > > 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!
> > >
> > > > -----Original Message-----
> > > > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Konda,
> > > > Tirumaleswar Reddy
> > > > Sent: Thursday, July 11, 2019 5:07 AM
> > > > To: Roman Danyliw <rdd@cert.org>;; The IESG <iesg@ietf.org>;
> > > > Cc: tram-chairs@ietf.org; draft-ietf-tram-turnbis@ietf.org;
> > > > tram@ietf.org; brandon.williams@akamai.com
> > > > Subject: RE: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-
> 27:
> > > > (with DISCUSS and COMMENT)
> > > >
> > > > Hi Roman,
> > > >
> > > > Thanks for the review. Please see inline
> > > >
> > > > > -----Original Message-----
> > > > > From: tram <tram-bounces@ietf.org>; On Behalf Of Roman Danyliw
> > > > > via Datatracker
> > > > > Sent: Thursday, July 11, 2019 4:20 AM
> > > > > To: The IESG <iesg@ietf.org>;
> > > > > Cc: tram-chairs@ietf.org; draft-ietf-tram-turnbis@ietf.org;
> > > > > tram@ietf.org; brandon.williams@akamai.com
> > > > > Subject: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-
> 27:
> > > > > (with DISCUSS and COMMENT)
> > > > >
> > > > > 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
> > > > > 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-turnbis/
> > > > >
> > > > >
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > --
> > > > > DISCUSS:
> > > > > ----------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > --
> > > > >
> > > > > (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.
> > >
> > > Thank you.  This text would address my concern.
> > >
> > > > > ----------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > --
> > > > > COMMENT:
> > > > > ----------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > --
> > > > >
> > > > > (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)).
> > >
> > > Understood.  Could we say something on the order of "if a client
> > > supports both MD5 and SHA-256, the latter SHOULD BE used"?
> >
> > Yes, modified the above text as follows:
> >
> > Note that if the response contains a PASSWORD-ALGORITHMS attribute
> and
> > this attribute contains both MD5 and SHA-256 algorithms, and the
> > client also supports both the algorithms, the request MUST contain a
> > PASSWORD- ALGORITHM attribute with the SHA-256 algorithm.
> >
> > Cheers,
> > -Tiru
> >
> > >
> > > > >
> > > > > (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.
> > >
> > > Understood.  I can live with an argument that turnbis shouldn't
> > > modify the behavior in this case given this additional (helpful) language.
> Thanks.
> > >
> > > > >
> > > > > (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
> > > >
> > > > Done.
> > >
> > > Thanks.
> > >
> > > > >
> > > > > (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
> > > > https://www.howtogeek.com/403771/why-do-some-websites-block-
> > > vpns/)
> > >
> > > Right.  I didn't know if there was something fancier I was missing.
> > >
> > > I appreciate these changes and explanations!
> > >
> > > Roman
> > >
> > >
> > > > Cheers,
> > > > -Tiru
> > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > tram mailing list
> > > > > tram@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/tram