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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 10 Jul 2019 15:49:51 -0700

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.

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

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 11 Jul 2019 09:07:29 +0000

Hi Roman,

Thanks for the review. Please see inline

> -----Original Message-----
> From: tram <[email-masked]> On Behalf Of Roman Danyliw via
> Datatracker
> Sent: Thursday, July 11, 2019 4:20 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> 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.
> 
> 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.)
> 
> 
> 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.

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

> second request buffer timeout

Done.

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 12 Jul 2019 01:30:08 +0000

Hi Tiru!

> From: iesg [mailto:[email-masked]] On Behalf Of Konda, Tirumaleswar
> Reddy
> Sent: Thursday, July 11, 2019 5:07 AM
> To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Subject: RE: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27:
> (with DISCUSS and COMMENT)
> 
> Hi Roman,
> 
> > Cc: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > 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.
> >
> > 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
> > (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.
> 

Thank you.  This text would address my concern.

> > (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).
> > 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"?

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

> > Recommend citing Section 6.3.1 of [draft-ietf-tram-stunbis] as source
> > of 40 second request buffer timeout
> 
> Done.

Thanks.

> 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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 12 Jul 2019 09:12:45 +0000

Hi Roman,

Please see inline 

> From: Roman Danyliw <[email-masked]>
> Sent: Friday, July 12, 2019 7:00 AM
> To: Konda, Tirumaleswar Reddy
> <[email-masked]>; The IESG <[email-masked]>
> > From: iesg [mailto:[email-masked]] On Behalf Of Konda,
> > Tirumaleswar Reddy
> > > links or open attachments unless you recognize the sender and know
> > > the content is safe.
> > >
> > > 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
> > > 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
> 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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 17 Jul 2019 12:33:37 +0000

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

> From: Konda, Tirumaleswar Reddy
> Sent: Friday, July 12, 2019 2:43 PM
> > > > 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.
> > > >
> > > > ------------------------------------------------------------------
> > > > --
> > > > --
> > > > 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.
> > >
> > > > ------------------------------------------------------------------
> > > > --
> > > > --
> > > > 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"?
> 
> 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
> 
> >
> > > >
> > > > “The client and the server MAY include the FINGERPRINT attribute
> > > > …”, why is the sending of SOFTWARE not a “MAY” too?
> > >
> > > 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.
> >
> > > >
> > > > review) Recommend citing Section 6.3.1 of
> > > > [draft-ietf-tram-stunbis] as source of 40 second request buffer
> > > > timeout
> > >
> > > Done.
> >
> > Thanks.
> >
> > > >
> > > > 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

---

From: Roman Danyliw <[email-masked]>
Date: Sun, 21 Jul 2019 16:10:55 +0000

Hi Tiru!

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

Roman

> [mailto:[email-masked]]
> Sent: Wednesday, July 17, 2019 8:34 AM
> 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
> 
> > > > > From: tram <[email-masked]> On Behalf Of Roman Danyliw
> > > > > via Datatracker
> > > > > 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
> > > > > information that is particularly sensitive”, wouldn’t the
> > > > > USERNAME and REALM potentially be privacy sensitive?  If they
> > > > > 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).
> > > > > SHA-256 if there is a choice?  Is there a reason not to
> > > > > recommend that implementations “SHOULD NOT use MD5”?
> > > >
> > 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
> > > Understood.  I can live with an argument that turnbis shouldn't
> > > modify the behavior in this case given this additional (helpful) language.
> Thanks.
> > >
> > > > >
> > > > > accept allocation or channel binding requests from addresses
> > > > > known to be tunneled”, I concur with the advice.  How would one