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

Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 10 July 2019 22:49 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tram@ietf.org
Delivered-To: tram@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D562812006A; Wed, 10 Jul 2019 15:49:51 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-tram-turnbis@ietf.org, Brandon Williams <brandon.williams@akamai.com>, tram-chairs@ietf.org, brandon.williams@akamai.com, tram@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.98.3
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <156279899179.15443.1948808943181719878.idtracker@ietfa.amsl.com>
Date: Wed, 10 Jul 2019 15:49:51 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/tFjLJgtoAIEGJFmrwO-L-qXzpWs>
Subject: [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
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: Wed, 10 Jul 2019 22:49:52 -0000

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:


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


(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”?

(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?

(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