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

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Fri, 12 July 2019 09:13 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 9A84212032C for <tram@ietfa.amsl.com>; Fri, 12 Jul 2019 02:13:05 -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=ham 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 j41NyywoGbqt for <tram@ietfa.amsl.com>; Fri, 12 Jul 2019 02:13:01 -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 2CFD61202CF for <tram@ietf.org>; Fri, 12 Jul 2019 02:13:01 -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=1562922138; 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=FmAcN/5zUJZqq2Y92WIjm7JUzPwVLCcl5dVLrt vCvmU=; b=qWuPYVPWsWrgpXfh2C97/+KFfr8f4vfcrVK7PFwD J8rNpm55BX2VCPhRiqOw+PRv1gCy1MURhGxQ7x6j0nhbt0jOfZ /xJmfyVw2Z2VQlEDTrHG+LvkFB49JJTqaGVa5yv6ryCnlwf4Tg qJxZGT0QQdGi3Poi2i/urEQk5KnywNA=
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-312-bwMDTC1kNtemn6nGG7TNfA-1; Fri, 12 Jul 2019 05:12:54 -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_b78f_b0027be9_29de_49c6_a73b_b23ad5165d4e; Fri, 12 Jul 2019 03:02:17 -0600
Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 12 Jul 2019 03:12:48 -0600
Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 12 Jul 2019 03:12:48 -0600
Received: from NAM04-SN1-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 03:12:47 -0600
Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1547.namprd16.prod.outlook.com (10.173.209.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Fri, 12 Jul 2019 09:12:46 +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 09:12:46 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Roman Danyliw <rdd@cert.org>, 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: AQHVN3Hb8rvCrm8yiE+tXfblQrByi6bE8P0wgAFCzQCAAHZQIA==
Date: Fri, 12 Jul 2019 09:12:45 +0000
Message-ID: <DM5PR16MB170599B4382A90A390A3C2CAEAF20@DM5PR16MB1705.namprd16.prod.outlook.com>
References: <156279899179.15443.1948808943181719878.idtracker@ietfa.amsl.com> <DM5PR16MB17055D5E91DFEF395F011404EAF30@DM5PR16MB1705.namprd16.prod.outlook.com> <359EC4B99E040048A7131E0F4E113AFC01B33CE08D@marchand>
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B33CE08D@marchand>
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: [103.245.47.20]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5e571392-d30a-43fc-a44e-08d706a91a99
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1547;
x-ms-traffictypediagnostic: DM5PR16MB1547:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <DM5PR16MB1547399129E7BA28E320FEB3EAF20@DM5PR16MB1547.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00963989E5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(376002)(346002)(136003)(396003)(199004)(189003)(13464003)(32952001)(51914003)(3846002)(6246003)(6116002)(66066001)(478600001)(52536014)(486006)(86362001)(5024004)(6436002)(9686003)(55016002)(256004)(6306002)(14444005)(76116006)(71200400001)(71190400001)(80792005)(53936002)(229853002)(6506007)(446003)(54906003)(74316002)(68736007)(110136005)(66556008)(7696005)(99286004)(316002)(11346002)(66946007)(476003)(66574012)(5660300002)(76176011)(53546011)(102836004)(25786009)(81166006)(26005)(81156014)(186003)(305945005)(33656002)(7736002)(8936002)(8676002)(2906002)(66446008)(966005)(66476007)(64756008)(14454004)(4326008)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1547; 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: 2p2s1xH6NphUjtMl70Ml+j6QDqz/Nb91JV+uof6pza+yBNLyraZ9jsoW8bJ3ha0kbHwWaxTvyL/9EoHcG0Um64l/pRv2HxFMSJHdBRzszKsSs3Ht/YVLrrTlNCe7ExB8iwMHBDRza5sODFNzV92lIIWR58ueqrFsYu8195Pzn254FoUksUrgFx9rHUxSZWxxev1gl1Fm42qeSlb4Xof1XD4dBYJL20RiCHgye587Ya+hZLKO2Yb0lG05Lb4EUu887dMgo4EoDbgM7I3C2KIBrqbm/1xClkk3NxDec9AATugmZ3vM6bjiLOmwOMAurpW0lqm4QdritPUiHf/k3/pabfXnQF4YigXPl9e3Jwb8YYlW4CLFu9OIEcE7emCXIY9ybRFK+5VRKmYEtV/F+deUXbW1Z3obQIwJIFvwkqytU4s=
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 5e571392-d30a-43fc-a44e-08d706a91a99
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2019 09:12:45.9779 (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: DM5PR16MB1547
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.3
X-NAI-Spam-Version: 2.3.0.9418 : core <6588> : inlines <7118> : streams <1827123> : uri <2866671>
X-MC-Unique: bwMDTC1kNtemn6nGG7TNfA-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/habQp0MQiHHmt_YRFWhQj_cD5WQ>
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: Fri, 12 Jul 2019 09:13:06 -0000

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