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.

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

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

Done.

> 
> (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/) 

Cheers,
-Tiru

> 
> 
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram