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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

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 <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> 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 <[e-mail]>
> > Sent: Friday, July 12, 2019 7:00 AM
> > To: Konda, Tirumaleswar Reddy
> > <[e-mail]>; The IESG <[e-mail]>
> > Cc: [e-mail]; [e-mail];
> > [e-mail]; [e-mail]
> > 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:[e-mail]] On Behalf Of Konda,
> > > Tirumaleswar Reddy
> > > Sent: Thursday, July 11, 2019 5:07 AM
> > > To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> > > Cc: [e-mail]; [e-mail];
> > > [e-mail]; [e-mail]
> > > 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 <[e-mail]> On Behalf Of Roman Danyliw via
> > > > Datatracker
> > > > Sent: Thursday, July 11, 2019 4:20 AM
> > > > To: The IESG <[e-mail]>
> > > > Cc: [e-mail]; [e-mail];
> > > > [e-mail]; [e-mail]
> > > > 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
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/tram